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A TECHNIQUE FOR IPv4 MOBILITY FROM IPv6 NETWORKS 


1 FIELD OF THE INVENTION 

The present invention folates to mobile data communication In 
qeneral. More specifically, the present Invention describes a tochniqu© for 
?Pv4 mobility from IPv6 n^oike using Mobile IPv4 eignalllng sent over IPv6, 
together with a new Mobile IPv4 ^denslon. 


BACKGROUND AND SUMMARY OF THE INVENTION 

The following definftiona are introduced for the purpose of clarity. 

FA Foreign Agent: The primaiy responsibility of an FA is to acta a 

tunnel agent which eatabB&hea a tunnel to a HA on behalf of a Mobile Node in 
mobile IPv4. ' * • \ . 

HA Home Agent: The primary responeibllily of the HA Is to acS: as a 

tunnel agent which terminates the MobUe IPv4 tunnel, and wrfiich 
encapsulatea daiagrama to be sent to the Mobile Node In Mobile iPv4- 

lETF Internet Engineering Task Force: The IETF Is the 

standardization organization for the intemet community. 

IPv4 Intemet Protocol version 4. IPv4 is a natworlc layer protocol 

according to the ISO protocol layering. lE=>v4 Is the major end-to-end protocol 
between Mobile and Fixed End-Systems for Data Ck>mmunicationa. 

IPv6 ' Intemat Pn>tocol version 6, IPv6 is a network layer protMol 
according to the ISO protocol layering. IPv6 is the next generation end^to-end 
protocol betw^n Mobile and Fbced End-Systems for Data Communications. 

WIIPV4 Mobile IPv4: MlPv4 is an IPv4 mobility standard being defined 
by the IETF with the purpose to malce IPv4 networks mobility aware, i.e. 
providing !E»v4 entWes knowledge on where a Mobil© Node is attached to the 
network: The standaird Includes the definition of a Foreign Agent and a Home 
Agent. 

MN Mobile Node: The MN comprises both the Temninal Equipment 

(TE> and the Mobile Termination (MT). 

RFC Request For Comment: The oollectlve name of standard 

documents produced within the IETF. Each standard document starts with 
RFC and a number, e.g. RFC351 9 Is th standanJ for Mobile IPv4 NAT 
traversal. 
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Mofalte IPv4 is defining a Home Agent as the anchor point w*h 
which the Mobile Node always has a relationship, and a Foreign Agent* which 
BCXs as the local tunnel^endpolnt at the access network where the Mobile 
Node IS visiting. While moving from one IPv4 sub network to another, the 
Mobile Mode point of attachment (FA) may change. At each point of 
attachment, mobile IPv4 either requires the avallabiii^ of a standato^^ 
Foreign Agent or the usage of a co-looated care-of address in the Mobile 
Node itself in the case that no Foreign Agent Is available. 

The present invention aims at providing a method lor IPv4 
mobility from IPvS networks using Mobile IPv4 signalling together with a new 
Mobile IPv4 extension. The foflowlng references are also of general interest 
for the understanding of the present invention: 

Perkins, Charlie; IP Mobifily Support; RFCS344; 
httni/AvwwJetf.Qro/rfc/rfo3a44.txt: August 20Cg 

Tsirtste, Q- end P* Sriauresh; Network Address Translation - Protocol 
Translation (NAT-^PT); RHCSzeS;' * , / 
httd://www,iQtf.ora/rfc/rfc2766.txl : f ebruary 2000 ' * 

H. l-evkowetz and S. Vaarala; Motille IP Traversal of Network Address 
TranslationXNAT) Devteea; RFC3519;. . I* " 

httD:/Aww,latff-QrQ/rfc/rfd3S1 9.txt: May 2003 - * 


3 


SUMMARY OF INVENTION 

The following Invention describes a lechrvlque for IPv4 mobflity 
from IPv8 networks, using Mobile IPv4 signalling sent over iPvS. together with 
a new Mobile IPv4 extension. 


BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other obieots, features, and advantages of 
Itie inverrtlon will be apparent from the following descr^tion of prefen^d 
example embodiments as wofl as Ulustrated in the accompanying drawings in 
which reference characters refer to the same parts throughout. 

Rg. 1 l5 a flow nhart diagram showing a Mobile Node reglsterir^ 
from an IPvS network or returning to the home nfeiwork- 

Flg. 2 ia a flow chart diagram showing a Mobile Node registering 
from an IPv6 network configured wUh a IMAT-PT gateway or returning to the 
horn network. 
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DETAILED DESCRIPTION OF THE DRAWINGS 

In tha following description, for me purposes of explanatten and 
not limitation, apedlic details are set forth, such as particular embodirnente. 
circuits, sianal fttimats, techniques, etc. In order to provide a Ihoroi^h 
understanding of the present invention. Although apeclfic protocols are 
Serred to foflhe puiposo of facHitalion tha description, the present invention 
is not necessarily limited to sucaispeolffoprotix»le. However. It win t» 
apparent to one skilled In the art thai tha present Inveritlon may be practiced 
In other embodiments that depart: from these specific details, in ^her 
instances, detail description of well-known methods, devtoM. a™J^roui» are 
omitted so as not to obscure the descriptlon.of the present invention under 
unnecessary detaD. 

The present invention provides a technique for IPv4 mobility 
from IPv6 networt«,- using Mobile. IPv4 signalling «ine?sage5Uialaresent<^ 
IPv6 In thi^ technique a new Ji/iobile lPv4.oxlenaon is used to hold the IPve 
eare-of addjess 'of the KflbiJile'liida^^ ih pegtstlratlon Request. 

' ^iinc.r '.L'-tV',-" .-.j '•. 

iPtgiii^ "i 'iliust'ratesa Mobile^ioiae'ii'regiatering m a ^jj?^ IPv6 

slPvS 

care-or aaarjess'Tomw iviyunon'swip.; wh"" •^y-T.-yf — ''^^H®?^' , 

the Horns Ag&nl Vvruse'th'e'lF*v8 acldrew in th© extension as£ieend-point of 
the IPv4 over IPv6 tunnel that \b set up from the Home Agent to the Mobile 
Node. ■ • ,s ' i • 

Rgure. Z il!ustffttee a Mobile Node ^ 'registering In a visited IPvS 
network 5 that te cqnfigured with a NAT-PT gateway 6. Fn co-located mode. 
The Mobile Node wHl lookup the IPv8 address of llhe Home Agent from the 
DN5v6 server 7. When the IPv6 addrese te recefyed ffomf the DNSvS aen/er, 
the Mobile Node vnll send a registration request to the Home AgBfA iL over 
IPv8 with an extension containing the IPv6 care-pf address for the Mobile 
Node. The packet oonlalning the registration request will be translated from 
IPvS to IPv4 In the NAT-PT gateway and sent over IPv4 to the Home Agent 
Upon receiving the registration request, the Horrie Agent wfli use Jie source 
address of the registration lequest as tha ond-pomt of the IPv4 UDP tunn I. 


DESCRIPTIONi OF THE INVENTION 


f h© fir?t situation described Is when the Home Agent is 
configured with an IPVjB address and when a Mobile Node registers co- 
kDcated from aivlstt^b'lPve network. The Mobile Node has aqulied an iPv6 
address In th V^stted lPve network, how this is c^^e la oiit of the scope of 
this pat nt app«cat(dn. The Mobile Node will thei>.send a registratfan request 

:!• 
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to tts Home Agent «aver IPv6 with an extension conyalnlj^ fio IPv6caie^ 
address of the Mobile Node. The care-of address field m the repBirabwi 
request is eat to zero. When the Home Agent lecejve the teglatratlan request 
It will use the IPv6 address in the IPv6 care-of addreM. e^^nsion asttie 
tunnel end-point address when setting up IPv4 ove.r IPvB tpnrtelmg ^ the 
Mobile Node. How the IPv4 over IPv6 tunneling Is set up is outside the scope 
of tWs patent appKcaBon. When tunneling has tieen set uo^e Home Agent 
wUl sand back a raglstmUon reply to the Mobile Node oveij IPv6. 

The second situation described is wrhjen the Home Agent is 
oonfiaured wHh an IPv4 address and a Mobile Node regls^rs co-Iooated f rewn 
a visted IPve networit that is configured with a NAjT-PT gateway. The Mobile 
Node has aqulred an IPv6 address in the visited iFJvQ netvjork. how this is 
done is out of the scope of this patent application. Pef ore «ie Mobile Node 
send a registration request it will first have to do a pNS loblojp from the looal 
DNSv6 server for the IPv8 addiegs of the Hoa» Agent. T^e returned ny\^ 
address willoontaifi;the IPv;tjaddrasis.of tlis. Horn© Agent as described inthe 
NAT-PT RFC.2T66..The.lUlotjIle NodajpilH P^en send a registration rwusst to 
' the IPv6 ad'dress"r6ti1eved;fr6m.the DNS server, tcjgetherlwlth extension 
containing the IPv6 care^of/addie^s of .tK©iMoWle:Node. %e packet ^ - 
oohtalning the- registration rsqu^ vrill b.e transliat^.f rom }P^ to ll=!v4 in the 
4MAT-PT gateway, and.sentilp,the.lPvi4 addinaaa of ithe; Home.AgenL When 
the The Horne Agent^iivill autllenti(^ertlie.Mobite i«?ttJe arp as.the <»rf-of • 
ad'dress field is, Bet .to'zs'rii in:lhe'i^ftistjrati^h r^qHe4t, Ihe JHoro? Agent will set 
uplUDP tunneling to the source IPv4 address.ln.the cegis&alioi^ request, as • 
defined In tl^ t^AT Siaveraal RFC 351 9. When UOp tunneling has been set 
up; the Home Agent wUI send back a registration reply to fhe source IPy4 
ad'diese in the registration request. The packet containing the registration 
reply wW be tiansleded from IPv4 to IPv8 In the NAT-PT gateway and aantto 
th£ iPv6 address ol the Mobile Node. . , I 

i If a Miabile Node moves from an IPv6 «6two|k to Ite home IPv4 

n^vrark It will de-reglster from the Home Agent Upon receiving a de- 
reglslratlon request the Home Agent wBl remove blndfig entiy for ttje 
h<5ne address of the Mobile Node and atop tunneling to the Mobile Node. 
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Abstract 

During the last few y^s SO cellW rtetwoTks are etattlBg 
it is ttot luitil the neacfc generAtiou of ceUuIar aetworks»;4G, tlj__ ^ 
mt«. are high cnongH to motivate i^seis to be mobJlo at ;aU 
probably transfer dacfca and voic^i <ivei' the ne«t ^neratlon Internet 
due to the missive amount of IP AevJces predicted to be iised around tho -srcrid. 
Mobile users can today mc Mobile IPv4 fi:OX» coUular access nctrorto to connect 
their laptop or handheld device secAely U> the homo network tcjusc mtexnal afvi«^ > 
but Mobtlc TPv4 caimox be Hfied to aeli^er lif>v4 mobility from IPv6 a««» 

The pnrpose of the work presaited fai this thwis )s to propose axid Jmptoent 
a »obtaon for Mobile IFv4 ^hat eW mobile uaexB to roam ^^f^^L^^^^ 
access networks that are liwing different versions of the Tnfceniet Frotocoi, Tffniie 
mwntwiiirtg A secured IPv4 comi^stion to the home netvrorlf. to V^^^^l 
part tho proposed solution is pres^iterl, how it works ^tod why it la ne^. O&M 
mechajiiBmB IhBLt sre available are discussed and togethjer they are combined into a 
complete fiolution that can deliwr ipv4 and IPv6 mo^whty from any ae«66 netWOTk- 
The proposed solution developed clunng this th&ns iu iixifilfiTnentcd as a pxoto- 
type in ipUr.plug^'s Roamias Ckew^y and Beaming Ghent products to dCTioiL- 
titreX^ how the sohition caji be iSaed. lb teat the implemptatioik a comWned 
lPv4yiPve l«*t network is act upj in a controlled lab 'eifmropnifint. In the ttjeo- 
rebical ev^u*itiOn the functionality, perfeDrmance ftud 'uaabillty of the wlotion is 
analysed, 'i * • 
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Preface 


Th6 work letuXin^ to this master theals was perforniBd dm^In^r the fiutiunn 2003 
eJi^ ipXJDplugged AB in Stodcholm, Sweden. Tbie mwter tlicels coxicludfis tlj© an- 
Uior'e Mw\er oT Science ediicatlon Iw Computer SiA^W^ ^nd EnjgJnoerlng at Ltdoa 
Uiuveieity of TbchsQloey. 


Pxirpose and goal 

The main object of the work behind this fcheaa is to inycstiEaCe Lorw thfi trsrsitioii 
from networks usin? the current Interaefc prcrtocal to jiefeworkB lunng the next gen- 
cration Internet protocol can be done as efflcienttlyand traaissparcntly as pcssihte 
for mobile uaci-a. Cmrently the focus of -curTent methods are inoatay oa stationeay 
users, b\at the traTtaitton is more complicated for mobile users because of thew be- 
havior, i.e. they are moving becweeu networks that may use «UffeflrenA vorsloisfi of 
the liiteiiiet Protocol- R>r inetaace, a mobile wer cwa coniiBct to m JPv4 network 
at the office, but when the uaer leaven the office and traveto by train to a customer 
meeldng, the only inteniBt access avaSIable may be thxou^ a oeHiilar phone eenace 
runntog on IPv6. How caa mobfle iisffls mate sure that they cm seamlesdy and s&. 
curely access their home netwotlcs regardless of the Internet Protocol used m ^cess 
notworlcs? ^ , , , 

IP Unplugsed Is a devoloper of Mobil© IP-based networking products which en- 
able mobile users to seamlessly and socutely J^o*??,™^ 
netwoi-Tc Indvidiwg t W^s, wireless LANs and 3G (OPRS, UMTS and CDMAmco). 
Curreotly ipUnplvgged's product* support IPv4 networks, but the goel of thjs tu^^i? 
i$ to prt^poee end hnplemeast a prototype ofasolntion that allowd users 
p3iigged»s solution \o seemleesly end sec^trely access their home networke regsrdle&s 
of the Intemeb proloool used in access nefcworhs. 

Demarcations 

The solution presented in this thesis is not wi IETF PETF] standard a^d t}iere Is 
no IjitOTiet draft Oiat describe the method used. The solution developed durmg 
this master thems is an ipUnplngged proprietary eralutian. 

Organisation of this thesis 

the thesis is organized as follows: 

• Chapter 1 - Introduction. Here is the cuirent and next generation Intomat 
prolocol presented, as wdl as the mobile user behavior and the problems 
asjsocieted with the next Keneration Internet protocol for mobile users. 
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• Chapter 2 - TVaneition lo the Next Geneiabion Internet Protocol. Thfe djapter 
presoDts the details of IPv6 and dificuBses the transiUon IPv6 a»U the 
methods available to mako tho transltlcm as smooth as possible. 

• Chapter 3 - Mobility Between IPv4 and IPv6 Networks. Here is mobilfty 
between diSeient nefcvorliB cUscuased and a new extension to Mcjbife IPv4 is 
presenter! ass a solution for seam1c»s 3Pv4 Toobijity vrhcn mavmg between IPv4 
«id IPv6 access networlcs- 

• Chapter 4 - MobUe IPv4 over IPv6. This chapter describee the d^italte of tbft 
now solution for Mobile IPv4 that was doveaopod duxinB thfe m^Kter fcUBSis- 

• Chapter 5 - Implementation. Her© is lihe implemenialioca process of the new 
Molklc IPv4 sdntion described. 

• Chapter 6 - Evaluation. TWs chapter evaluates the implementation of the 
Mobllo IPv4 over 3Pv6 solution In IpTJnplugged's products. 

• Chapter 7 » • Conclusiotn. Tbi& chepner concludes the mt»*tet theas and pws^t© 
-work escpeciencaes and ccmcliimonM. 


Acdmowledgements 

I would like to thank my supwisor Hans SjSstrand at ipXJnplu^ged AB, and ex- 
aminer Androas Jonsson at Lulca UniverfilSty of Technology for their advice and 
support. T thank all people at ipUnplneesed AB for making the everyday work more 
pleasant and joyrul aJid I would e*^cially like to acknowledge Peter Larason and 
"ESrlk Uden for thdir tedhiiical ad>nce and support dnxins bhe prototype n/ipleiAen- 
tAtion. 


BEST AVAILABLE COPY 


n^^,, I IRDTO from the IFW Imaqe Database on 02/22/2005 


15/01 *04 18:25 FAX 46 8 31 67 67 


GROIH & CO 


-¥ BANNER & fflTGOFF Q|014 


Chapter 1 


Introduction 


Internet IS the largest network Sn ead&tonce, anU il w conelanlly growxnff. The 
m^-ve nmnber of IP derices that' are piwdicted to be used sroiand the -world In 
the auBT future has bnm^ forward the nwd for a xevlsicm of the cmrently used 
InCemeb ponytocol as the eurrently used protocol Is not eacpoctcd to ctipo with the 
needs of the fkitnre. 

!•! Aja liiteriiet Briefing 

Internet .is a large global network that consJst & voBt oxnounl of mtercoimected 
nefcworleL TU^ netwrla are interconnected through routere, vrhich hosicaUy axe 
oompntei^ with several networks attached to ihem* The task of the router Is to 
jsend data belw^ the different networks. .The routere togebher "vtth an'addresshig 
sjrstcm and a transport protocol, called the Internet Protocol [I^P^*!. mates 1* possi- 
ble for An arbibrary coriiputcr to reach other computer attached to the Internet. 
Tf a router along the path to the destination -would feilj tliercfe are mechaiolfiitkS th»t 
moy find another way to the definm&tion if possible. This me«ul6 thet ell couiputexs 
connected to the Inlerciefc has to use the same a ddreasfa g system hi order to send 
data among each other. 

DuriYtg the leeti few ^ears, tho number oT IP devices connected to the Internet 
has irirtually exploded end due to the ailocafeion mechanisin that is used to allocate 
addteses iza the Internet Piotocol, some perls of the wco'ld axe beginning to run out 
of addx«s»ss, A new -vensSou of tfie ibtemet Piotoool called IPvG {TPve) hna been 
defined that solves the address shortaee problem as ^eD as other problems with 
the eucxentV used Internet Protocol* The new protocol Is howovev not b&dcwacds 
oompatfble, and it is therofbre hard to deploy in the Internet. 

1.2 Mobile Users 

Mobile xi$ei3 are different from stationary users In the way that they often move 
between different noftworks to connect to the Internet. A normal day for a mobile 
«»er may start at tlie office, connected to the local network either via LAN or 
wirelEss LAN. hi thi» environment the user can access the necessary services, such 
Kus iTiLranet, mail servisr, fil^ «itorage etc When the mobi;« "»«r le^vev the office 
and talcee the train to meet a ciiatomer, the user may u^e a cellular phoxi**- Service 
to connect lo the Internet to send a. mail or get some documcfnts. In order for t|>e 
mobile user to uye the services normally available in the office, a mobile VPN is 
needed. MobllR XP lMIPv4] is a protoccil ihe-t malses it possible for mobile uacra to 
maintain their TP address in their home network, while connected to other access 
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Tictworks outside of the hoiriQ nQtwork. This will xodke in yctatdble for the mobila 
uaejt to axxess services th$t dxe only ovsilabls in the hoxnd uetvork. Howefviiry the 
pos3ibtliby to access senrviq^^ that &re usually only available Jn the home Det^'Ork 
introduces security i$sue5. The Mobile TP etaadard does not define how to secure 
the trafSc, t.l^is itf -vrh^* a separate secxirily mechanism Is needed, IPlseu [IPeec] for 
example. Mobile IP with JP^Q can deliver a s«cuxe seaiiiIeK» mobilily EoIutJou tO 
a mobile user. Access tietvorks» such as GPRS, ODMA2000 and TJMTS today uue 
IPv4 as the netwt)rk protocol, but in the near future cellular phone services are hke^ 
to use IPv6 Afr network protocol as IPv6 uses a large addnM»$ spwe^ 4>ulUible for the 
lar^ predicted emouot of mobile devices running on IP »udb as cellu l ar phones avd 
hand-hisld computeis. To use Mobile IP for sefijsiless xnobility while xunniug IPv4 
s^plicatioi}«> it is todaor requited to be connecfted to en IPv4 aicceas network. 

1.3 Problem Statement 

Ibday alnjost every access network usea IPv4 as its network protocol, 5t is mostly 
in experimental networks that IPv6 is psed. Hcwtf^m^, it is lUo&Iy that TPvfi ^vill be 
tised in the nesct generation of cellulai* Tjetworks. One example is the experimental 
4G cellular n«twprk that NTT DoOoMo is irking on poCoMn], which uses TPv6 
as network prutocoL 

In order lo depli^ IPv6, in wccesss nDtw9r]^,, it is importonli that wd usera do 
not need to reconfigure, their compi}ters whenever they connect to an rPv6 access 
network and that they can re^ch services tiiat are available In the TPv4 Internet. 
Thfa is "wby several tr^iJisitlon ^nechanism^ have been devoloi>cd t])at cian be used 
to make the transsmon to IPv6 as smooth as p^Bsiblo. "For CKaoOQple, by using an 
TPv6 capable web browser and a transsition mechanisms that translate IPv6 traffic 
to IPv4 traffic tnsikes it ]aossibIe to vf!*M:h IPv4 servit;cs s>n the Inwinet from an IPv6 
access neuwoik. Bui as most app1jc>«tions today onJy support IPv4 thsre is a need 
to still be Hble to run IPv4, appUc^Uons when connected to an IPv6 access network. 
This is espeoicdb'' true when it comes to mobile usere that want the possibility to 
securely connect to the^r home network to reach IPv4 services. Mobile IP solves 
this problem when the user i8 connected to an IPv4 access network, but when iPv6 
access networks ai-c being deployed, Mobile IF cannot deliver IPv4 mobili^ from 
thcstCi access netwiofrks. This is why tl>ere m a seed for a solution thaL can deliver 
n>v4 mobility £i*Din IPv6 access notworki?- How can thia be done in a way that does 
not introduce unnecessary invcstmentv in JPv6 Infira^trvcture? 

1.4 Thesis Solution 

The work presented Jn this thesis is a proposal and implementation of a solution fbv 
Mobile IPv4 that allow mobile usctk to move firoely betw^^ access networka that 
are osin^ diifci'ertt vexskms of tlie Inxemet Protocol, while maintaintng a sc^eure 
IPv4 connection to the hoine network. Other solutions that can solve tiie problem 
piresonted in the problem statement ar^ aleo discusEsd and together th^ con be 
combined to a complete mobility soUition for both IPv4 and IPv6 mobility. 
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Chapter 2 




Transition to the Next 

Generation Internet Protocol 


Bdforo trying to solve the iiroblem mtrodui;^ ia the problciiix «i.aVeinent^ it Is iiecs- 
cssGxy to Inio^ vrhat h€U8 already boem thieved in this area. This chapter begins 
^ith £L pzesentation of the cuxrently used Inl^rnet Pn>toco] the new successor 
IPv6. Ia tbSfi diApter mechanisms thAt can be used to make the transition to the 
next generatioYH lulemet Protocol 9$ emcoth as ^possible are also discussi»d. 

2.1 The Ciirrent Internet Protocol 

The cuirent Intemtst Pxotocol, ffSr4, ■»»» standardissed in ARPANET RFC roi bj 
19ai [J[Py4J. IPv4 has been the moat unccesaail network protocol ever doploj'wd. 
Ckmsiderjx^ it ttra«! one of the fitst network protocols, the durability of IPv-l has 
been b^ter than expected. Today, however, with the growth of the Intcrnotj th^ 
developsient of a global biislnefis environment built upon the Internet i.he ad- 
vaneea in technoIa^» IPv4 threetens to hold back the techn i cal iiexIbDity of the 
Internet. 

2.1.1 Adtdross Space 

IPv4 has a 32-bit ^dilxesa $pBjce that Atlowa Jfor 2*32 or 4,294,967,296 possible ad- 
dresses. In the Utc igTO's when the TPv4 addxees spaice >vae designed it was uninia^ 
Jneble that it could be exhansted. However, dne to changes in te{^nolo|Q^ end aa 
allocation pra«ti»e (hat did not anticipate the recent growth of hos^ on the In- 
ternet, the IPv4 address spBoa was coiifiuuied to the poffit that by 1992 it was 
clsaT th&t » xeploeemcnt protocol mold be needed. In a world where all comput- 
ers are connected to tjie Internet and* when the future world looks to be fiill of 
new devices 6hat will be connected to tl^e global netwotfci like j>ortable phntnea, 
PDAs, Internet appllnttCeo. vehicles etc, there is simply not enough addresses to go 
around. IPv4'5 usablfi life has been extended via a technolojgy caviled Hotwork Ad- 
drcBQ IJranslotlon (NAT) [NAT], which iv a clever mechaniBm that conservet? sGarce 
IPv4 adOnssses. BssentlaUy, KAT allows enterprises to deploy t»ol«ntially largo not- 
works uanng tshared IP-addre$sine space, tO.Q,0.0 or ld2.16S.0.0 for example, and 
tzanslatSng (heir [ntarnet-boimd traffic at their nctwot-k ed^ to unique addrcsRufit 
assigned to theh: enterprise. In this way, an enterptise cau deploy a ttiouaand of 
computere and reserve few unique IP adciresses. NAT Is elfective in that way that jt 
allows more nodes to Join the network than would be possible ir all nodes required 
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Toutaible axidrc«ses. This capability comt»; vibh. a cost, the loss of end-Xo-end coro- 
znuDjcation, ivhich achranc<id aptpJlcations often require. Many spplicatioiiB today 
requires advanced workaiound$ to traverse NAT gatewaya, which creates unneces- 
sary technicaUy coxnplicas^d oTchitecturos. 

2.2 The Next Gexieration Internet Protocol 

Thcb n«x« seneraiion Intemot ProiOGol Is called JPv6. It viSeB 128 bit oddrcssea, 
which is four times larger th«n an IPv4 address, Wiih IPv6 it is hard to concalvv 
that the IPv6 address space unth ita 2^12$ addicases vUl ever bo consumed. The 
relatively lar^ sisfie of the IPvd addx«ss is desig;D8d to bo subdivided Into hieroxdiDl 
routing domains that »£ect the topology of the modorn Tnteim«t. The 128 bit 
address provide multiple levete Ol hierarchy oad flesdbilii^- to designing hierazchiical 
addresaing and «nitmg, which is currenUy lacikiug th« lPv4r-based Internet. Tho 
architecture of IPv6 le dedcribed in RFC 2373 pPvCg. 

2.2.1 Header Chanses in IPvft* 

Since the IPv6 addresses are fowr times laiger than TPv4 addre^es, the format of the 
JPv6 header had to ba c1>ao^ed. Thia chaz^ alloyBed tb<* dfi^slgcera of the protocol 
to redesign the header fictbsLWatch and tihalce St better tjhan its predecessor. The 
IPv4 header contains fi^da thab have hacxi, discarded in the IPv6 header, as shown 
in figure 2.1. " . . ' . ' • * 
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Pigixra 2.1: The IPv4 header forniax. 

The header format hasbeen simplified in IPv€, the sbadetl fields in Hgui^ 2.1 does 
not esdsl in IPv6, as shown in ijgvre 2.2, Despite that, the JPv6 header ie ttiiU twice 
as large as the IPv4 header. The IPv4 header tenglh J» 20 bytes ^thout options, 
to be comparod to the IPv6 header length which ia 40 bytea. One of Uie important 
changes is that thera Is no options field ia the IPv6 header. In IPv4 the options 
field can be used to add infannation about various optional services, for example 
infcnnatlon rotati^ to encryptian. Bocauee; of tlus, the IPv4 header length can vaty 
depending on the sitTiation. Due to this difierence in length, routers that contiro! 
coxmnuntcatioua according to tho in jbrmatiDn in the IPv4 hoad^r cant Hssvme that 
the IPv4 header Bi2e is fboad, which makes it difficult to speed up packet proceasinB 
witli hardware assist. In IPv6, infoimatios related to additional services is moved 
to an cxtonrfon header, in that eaise the type of e}cteuaion headvr ia aLorcd hi the 
next header Jjeld. The IPv6 header In Bgure 2.2 is called basic header, thia meas» 
that for plain pacJkeCS the length of an IPv6 header is fixed to 40 bytes vrhidi makes 
it easier to speed up packet processing vlth hardwiuo asaSst. 

Another field that exist In figure 2.J but not in figure 2.2 is the Hcsadcr Checksum 
fi«ld. A header checksum » calculated ueiTig the numbers in the header and it la 
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Ensure 2.2: The IPv6 headcar fojnnat. 


u»ed to check for mois ia the ticader iiifbnnatloT). The problem this appiroach 
is that the hesudez cofntajns & field called Time lb Live, which chai}^ ^very time 
the pafikeb ^es ibroaish a xcnatec. This means that the Header Gheckmmx has 
td lie recalmleteU evexy t^me the peckBt gp^' through, a router. If we could free 
up routers from calcnlaticms lSSi» Lhese, the dele;y could be reduced. Activdly, «he 
transport la.:^ header, TCP- or UDP for in^tiwce, elso has a Header Checksum field 
which cfaeclcs for erjoxa in vaaiaus information, including the source and destination 
addresBes in the IP header, ^iace perfiomuxiiff the same ca]cvI»Uon» at the IP lasfer 
is redundant and unnecessary, Header. Chedcsom is removed Ixom IPv6. 

The 8-to *<T|ype of Servie^ field in figure 2.1 may be used by ncftworkiS to 
define the handling of the datagram during irsnspcrty for example the priority ol 
the dataeram. IPv6 provides the same ftieetion with a field callod IMfie Class. 

The Flow Label fidd in iigiue 2.2 is of 20-bit length and is a field newbr estab- 
lished ftir IPv6. By using this field, the padkeVs sender or iutcnnediate devices can 
specify a series of packets, such as Voice over IPs as a flow, and nequeec particular 
senrlce for this fioiv. $ome IPv4i devices are equipped with the ability to recognize 
traffic How and e«9jgn particular priority to each flaw. However, these devices are 
req^ured to net only chedr IP la^ iziTozmation, th«y also has to check the pott 
number which is information that belong to a higher layer. The Flow Label field 
attempts to put together all necessary In&rmation and provide them ar tlie IP Isjyer. 
However, specifics on how to use ife is still undecided* 

To conclude, IPv6 aims to provide an hxtemgent trsnsmission firomewoik that 
1$ easy to hsndle far intermediate devices by keeping the baflc header simple and 
fixed in length. 


2.3 Transition Mechanisms 

The next generation Tnternet Protocol is wot backwards compalibie with the cuiroirt 
Internefc Protocol, this makeB it hard to depliay the ucact goneration Int^net Protocol 
»3 old applications will no longer work. In order to make the trensalaon to IPv6 
as trouble tcee as possible, a number of transition mechanisms Tisrve been defined. 
The following Iv a brief overview of some of the transition mecrhaniams that the 
ngtrans lETP woridag group [ngtrens] is wovkShg on. A few of thom are already 
IETF proposed atimdards, HFCs, while others axe stiU Internet drafts. 
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2.3.1 EEiTF Proposed Standuds 

Ccnmc<:tton AtlPvB X>oniaxiis via. IPv4. Clouds (6to4) 

TJ)ft 6to4 Iransition mecTaanisifn \B an 1£7TF standard and f3pR<rifl«l in RJFG 3056 
{6to4]. Tlds traji5fitioi> Tnecliamem is nonnally used wlicrti one IPv6 network needs 
to be connected to wiother IPv6 network as St provides a wy tQ connect IPv6 «Qdr 
site networks l:^ automatic timneJing over the interveninff IPv4 Internet. A special 
IPvB routing prefix (2002::/! 6) is ii«ed to indicate that the remaining 32-blt$ of 
the external rouiang prefix contains the 1PV4 end-potnt ftddre5$ of e. boundary IPv6 
router for that sjte tliat wiU respond to TPv<i hi TPv4 enc»p«iil^ition, Thia will aJlovr 
aliost that is loc^^ted behind a 6to4 router to communicate with other ©to* hosts on 
the Internet. When the host sends An IPv6 packet to anothor 6to4 host, tho pncke* 
is tunneled in IPv4 at the 6to4 router u$i jcjg the IPv4 address cozitained in the pr«^X 
of the 6to4 destination addrcsss as the IPv4 destination address. At the destination 
site the IPv4 header is removed at th« 6to4 boundary xonter and ftarwardod to the 
appropriate 6to4 host 1^ using the IFSr6 xoutzog infrastmctuTo of the de&tinHtion 
site. 

By naing a 6to4 replay router, a 6to4 host caai $entl IPv6 packels lo a native 
IPv6 node on the IPv6 Internet. The packets are encapsulated in IPv4 at the 6to4 
Tonter and sent to the IPv4 address of the conBgured 66o4 relay xoixter. The relay 
router has native connecttvity to the IPv4 and !PJw6 Intomeb. Tho eto4 vdAy router 
removes the 3Pv4 header a^id Jofwai ds* the IP^' *«> the appropriate IPv6 

Internet host. 

Network Address 'xVanalation - Protocol Translation (NAT-PT) 

N AT-PT is a etandai-ds tmdt IETF RFC p^AT-PTl describing an IPv6/TPv4 trans- 
lator. NAT-PT allows native JPv6 hosts and .applications to comtnunieate 'With 
native IPv4 hosts aijd aprficaUons. and vlco'v6rea. A NAT-PT 'device resides W 
fehe boundaiy between an IPv6 and II>v4 notwtoj^. Eacli N AT-PT device retains & 
pool of globally jcoutable IPv4 addresses, wliich ax^ used to assign to JPv6 iiodes 
on a dynamii: basis afl sessions axe initiatt^d across tho IPv6/IPv4 boundaxy* In 
addition to aildresa translation, header translation is performed as d^ribed in the 
Snr mechanism (SUTJ. As opposed to SIIT, which, is a stateless translatlcm moch. 
anfsm, NAT-PT retains state vja the IPv4- toJPv6 address mapping whidi are 
retained for the duration of each sewdon. NAT-PT can be extended to NAPT-PT 
(Network Address Port TVanslaTJion - Protocol Oyattslation)- NAPT-PT takes the 
address translation a stage lurther by enabling the translation of port mixnberB as 
well. This makes It possible to re-use one IPv4 pool address and map tliis one IPv4 
address to many TPv6 hoete. The bckstc NAT-PT transbUon device may addition- 
ally contain ALCrs (Application Level Cotewayd). ALGs are necessary when IP 
addresses ai9 embedded within the payload of an IP packet. Bbr normal padcet 
translation. NAT-PT wonM not look within the payload for IP addrossos. IVpi- 
cal protocols that embed IP addresses in the payload am FTP and DNS. NAT-PT 
requires no spedisd configuratjon on the cHent, apart ftttiai wsJng the Coirect DNS 
server which can be config«ired aiitonaaticailly tlirough DIICPv6 lor example. 


Stateless IP/ICMP OQransIator (SBCT) 

STIT fSIlT] is a transition mechanism al^rithm that traoslate* bet*ei*« IPv4 and 
IPv6 psckel headers, indnding IC?MP, *m separate tronalator "boKcs" En the net- 
work, witUonL requiring any pGr-oonnieiCtiosi state in those "boxes" . This algaritiini 
can be used as a psxt of a solution that allows IPv6 hosts, whidh do not have a 
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permaixeutly assignee! 10Pv4 address, to commuiijcatc -with IPv4-on]y hosts. NAT- 
PT 16 Ml example of auch a solution. Tlie RFC ueitlxer specifies hew to do address 
alignment nox roDtiug Co and £rom the iPv6 hosts when they communicate with 
IPv4-only hosts. 

IPvd-to-XPv4 Transport Relay XKUiekttor (TKT) 

The ]F'v8-to-IPv4 Itansport SLelf^ Xransslator (TRT) flHT] work$ in a way tliat 
Is slmllAT to the NAT-PT mechaaism. The diSereDco fs that the TCP conne<^on 
£cDm an I]Pv6 node to en IPv4 nodo Is intercepted in the TRT. Fbr example, when a 
TCP packet from (he IPv6 node destined to the IPv4 node is Tcceived $X The TRT, 
^he TRT sfitfi ii|> » new TCP connection to tho IPv4 node and forwards the data In 
the packets fiom the IPv8 node- This mcaxiR that two TCP eonvieexionff are set up 
for every TCP sesaon. 

Una! Stack Hosts Using "Bump-In-thft-APP* (BIA) 

The BIA nicchAti]{>m [BIA] inserts An API translator between the socket AP J module 
and the TCP/IP module In the dutd st&ck hosts, to translate the rPv4 sotk^t API 
function to IPv6 uodcet APT ftinction and vice verea. This allows the transition 
to be simplified without IP header translation. When using BIAj the dual etaclc 
ho«t asromes that there exists both IPv4 and IFv6 stacks on Uhe local node. Wlxen 
an applicatlo/i an the dual stack' uommunicat« with other. IPv6 hosts, tJie API 
translatot <leieclB the socket API functions .from IPv4 applications and invokes the 
IPt6 socket API fanctaons lo communlcati with the IPv6 hosts', and vice versa. 
Til order to support communication betweeia IPv4 applications and the target TPv6 
hovts, pooled TPv4 addresses will be asaisned throiig^i the neme resohrer in the API 
transtlator. , ' * - ' 

2.3.2 IETF Internet psr^s 

Dual Stack IVansition Mechsonuatn CJOSTM) 

The dual stack transition medianlsro PSTM} is based on the use of IPv4-over- 
IPv6 tunnels tu caxry IPv4 trafQo wiUiin on IPv6 dominant network and provides a 
method to ellocate a t<anporajry IPv4 addrcsss to Dual IP Layer IPv8/IPv4 capable 
nodes. DSTM is also a way to avoid the use of NAT-PT for coiAinimication with 
IFv4-only nodes and applications. When BSTM is deployed In a kietwork, an IPv4 
address can be allocated to a Dual IP Layei* IPv6/IPv4 capable jtode to connect with 
iPv4-on!y nodes and applications, without modification to any TPv4-only nodo or 
application, or the IPV'I application on the DSTM node. This allocadon mechaaatem 
is coupled with the ability to perform TPv4-ovep-IPv6 tunneling of IPv4 packets 
inside the CPv&-dondnant network. Tbe DSTM mechaaism consist of a DSTM 
server and DSTM capable nod<s. The DSTM server is responsible for IPv4 Address 
Allocatu>n to client nodes and m^y also provide tunnel endpoints to vhe DSTM 
nodes. The DSTM nodes will use tunnel end points to tunnel IPv4 packets inside 
IPvS to a DSTM Border router. The DSTM bordei* router then decapsulates the 
IPv6 packets and transmits the TPv4 packets to the destanation IPv4 node. The 
DSTM border vouter will hove to cache the path hsds to the DSTM node for Ihe 
IPv4 addreas to funnel bbe packet in lFv6 to the origiiEial DSTM node. 

X>U9d Stack Mobfle IPv4 

The dual stack Mobila Tpv4 draft! [DuaJ-M1Pv4] provides TPv6 extensions to the 
Mobile IPv4 proloc(d. The extensions aSow & node that has irv4 and IPv6 addresses 
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lo xQaintain commiinScatioiis with tether oi both oT its addressed while nao>izig in 
IPv4 or dual ata«Jk networks. The Hpccification essentially separates the MohaelP 
signaling vewioii from the IP vertion of the traffic that tt tunnels. Mohile IPv4 
vrXth theue new extensions becomes a sibling pjcofcocol t])at Yuns ftw.ir IPv4, and 
y^t cau eel-up oiiy combinatioin of IPy4 and/or IPv6 over IPv4 tu»n«la- However, 
this metjhod cannot he uaed -when the user moves bo an IPv6 only access network 
£w the Bl^alin^ is only sent over IPv4. 

nual Stack Mobile IPv6 

The dual stAok Mobile IPv6 draTl [Diial-MIPv6) provides IPv4 oxtonfiioiis to the 
Mobile IPv6 protocol |M3Pv6]. The ea^onsions aMow a no<Je tba.t h9B IPv4 Mid IPv6 
addresses to io»m i»ithin the Interoet using Mobile IPv6 only, while siiinaianeously 
maintaining connecfcions using their TPv4 «id IPv6 home addresses. When the 
mobile user is located on a dual stack or TPv6 only access nelwork, the MobHe IPv6 
Signaling is sent over IPv6 to the Howe Ageiit. When the mobile nser is located on 
an IPv4 only access network, the Mobile TPv6 ^gnaline packeta are Uinneled in IPv4 
to the Home Agent. The drawback wl^li the dual stack Mobile IPv6 mechanism is 
th&t it does not htmdle sltnatlons wbftn only private IPv4 addresses ore available in 
the access notvork, V7h\<!h is a conunon situation. 

IDPvG over Mobile IPv4 ^ • . , - . 

TPv6 over Mobile IPv4 p>v0-MIPv4l specifies a Mobfle lFv4 eocteziBion that may 
be \i6ed by dual stack mobile nodes tt> obtain IPv6 service with the nse of a Mobile 
IPv4 registration. This coctcnstion ^gw.for innnediato doployaiont of IPvfl on dwal 
stack mobile devices, without the need Jbr a fulllPv6 infrastructure. It is believed 
tbafc providing? IPvG services to 3(nobiIe devices m the short term will spur th« growth 
or IPv6 networks. The 5[pccificatidu requires that the mobile node and Home Agent 
have dual IPv4 and IPve stacka. but there are no dmigt^ T.o.tlie PA and it does 
not need to be dual .stack. By using this m&dhtoif9m tcfisether witJi MlPv6, IPv6 
mobility cfva be tuilueved irom any tM»»sa network. 
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Chapter 3 

Mobility Between IPv4 and 
IPv6 Networks 

This chapter Snttrtduces * possible solution to th© problem wjth iDobiti^ between 
IPv4 and Tpv6 net^-orlss. H begins by pointins out soot© JSRves tliat are important 
to tftk^ into acccnmb wbem tsying to solve this problem. 

3ll Overview/ 

In a perfect worlO, it is possible to 5ntrodticse«cw network protocpto and mechaaurana 

only a small ssoaware upgrade. But taktng into account the masMve amount of 

networks deploj^ in tlie Interne* and tlie greater amount of users it^ not 

bftrd to realize thp* such an approach is not posaible. The deployment of IPvG is 

n good example of how hard St cm be 1.0 introduce something new when so many . . 

people and computers axe alfocted hjy the change. The reason why IPvfi is hlcely . • 

to be used In the next genoration or ceUular nebwcrica is the massive amount of 

devices that ore predicted to be used in these netwovka In the future, All <iver the 

wirld. There is sirijply not enough IPv4 addroeses to go sround- When it comes lo \ 

mobility, solutionB esdst today to both IPv4 and IPv6, bnt these aolutioiis do not 

soNe the problem with a xnscsd network environment, which la likely to be common 

once the access networks start to use IPv6. The eadstteg mobility &olu«on» will be 

premted below as it is necessary to understand how th^ work m order 10 solve 

the problenas with mobility between IPv4 and 3Pv6 networks. 

3.2 Exi^iiig Solutions for IP MobiHty 

The existing mobility standards for IPv4 and IPv6 wiUbe described brieHy to gjve 
the reader sai undeisCandmg of the two protocols. 

3-2.1 Mobile IPv4 

In gcnerAl on bho Internet, IP packi&tfi are transported from thoir source to their 
defltinotioii by aUowIng rontera to foward daJ,^. pwrkets from Incoming netvrark 
interfaces to outboutid network interfacea according to information obtamed via 
routing protocols. Routing taWw typically mftintam the »«xU-hop infoimalion for 
each dasi4naUon IP network. The TP a<idrew of a packet normanyspe«iC«s the IP 
cliftnt's point of attachment to the network, which means that the IP address has to 
change at a n«w i>oint of attachment, ^Cb Alter the routhig of IP packets totondod 
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16 CHAPTER 5, MOBIUTY BJBTWEEN IPV4 ANO JPV0 TfBTWOKKS 

for a motiile client to the new point of attachment requires a new IP address asso* 
ciated witli thai nevr point of attiujbmenl. However, to maintain exsar&ing transport 
protocol layer connections as; th^ dienl moves, tbe mobilfl dieut's IP Mldress must 
n»na)u the some. 

Mobile IP solves this problem by introdnclng ^wo aefw functional entittcn x/ithin 
IP nctmxrlca. Those are the Bsreign Aeeut, FA and the Home Agent, HA- The two 
now entJt!£» togeiher with enhanccntentia in the Mobile Node (client), are Ihe basic 
bulldhjg bJpcks for a Molnle IP enabled network. Tho last entity needed to provide 
a full reference for a basic Mobile IP enabled netyrark Is the Correspondent Node, 
CN. The Correepondent Node i6 another DP cutily, for example an intoniet Server 
with which the Mobile Node communicates. TJia CoiroBpondent Node does not 
ne^ lo have any Mobile TP knowledge at sHi, but the Mobile Node needs apgrading 
and new functions are required in the visitlns end home networfca. 

Mobile IP 'w>x)ss by allofirhig the Mobile Node to be associated with two IP ad- 
dresses* the "home" addre^ and the *'caiB^ address. Tbo home address remains 
fixed, while the care-of addjrftss changes at each new po^nt of attachmeni. to the 
Ijitemet* The home BP addrees assigned to the Mobile Node malces it appear as If 
the Mobile Node Is attached to its home neftwork. This 5» Uw IP address where tlie 
Mobile Node seenis to be reachable for otber luXemet clients and services. I«Vo]n 
Ihe view .of the CurrtSpondaot Node, tho Mobile Node seems to be attached to tbe 
home network independently of which network it is,cuixently visatini^ 

A mobile agent, tte Hgme Agent, iliat. I? provided in A borne network receives* 
traffic thax is directed tq the Mobile Node's hcMoeiP address eLven whcm thft Mobile 
Node is noc jAysically attajihed to the home, network. V/hem the Mobiles No<le is 
attached to a foreign netwoork, a Home A«Mrt; tiiniiel^ that traflOic to a fbreiBn Asenl 
n^ng the Mobile No^*6 'cuircnt care-of address. The care-of address identifies the 
Mobile Node^s cuiieii topological point ofatiliachment to the Internet, this ia wl^y 
Tihe care-of address cm be ni^ to tunnel pac&Sts to the Mobile Node. If the Mobile 
Node is attached to the home network, the Ho5bic Agent' simply arraagiiS to have 
tbe data traffic dclivezed'to the Mobde Node*^ poiiit of atta^luDiant in Lhe home 
network. Whenever tlm Mobile Node moves its ^oint of artachmeui:, it re^^cers a 
new oare-of address wtch Its Home Agent. 

When the Mobile Node is atta(*hed to a for^gn network, packets nmit Srom 
xh« Mobile Node can be sent direcUy to the Ctorrespondent Node. This is called 
t^iangulaz routing which bas one problem: as man^y rontere Iilteru ont packets with 
source addresses thai axe inconsiBbent wii^ their routing table (so called ingress 
filtering), private addressing cannot be irnmediately used when visiting a foreign 
network. The solution to this problem is a technique called reverse tunneling, which 
means that tbe Fbr^ign Agent also tunnels packets from the Mobile Node bade to 
the Home Agent instead of dti*ectly sending them to the Corteapondeul. i^Iode. 

At each access network, a Mobile IP client normally requlrvs a stand-alone fbr- 
<rfgu Agent. However, if the Access network In question dofjs not provide a Ibrdgn 
Agent service then it is possible to include a Oo-located CHx^Of addrees in the Mobile 
Node. The care-of address is the temporary address in the vivnted access network to 
which tho Homo Agent forwards incoming padcets and vice versa. The two diffd-ent 
ways of gctt1)ig the mobile node associated with a Mobile IP caio^f addr«SS, ueV 
wori£ bused ¥breign Agent versus Co-located care-of address, has somewhat clIfTerent 
diaractcristjCK. 

When a network based 1%ire3gn Agent is used, the Mobile IP tunnel is turimnaicd 
at the Bbieign Agosit In the netwrk. On the other hand, when using Co-located 
care^ addresses, the tumjel is terminated in the Mobile Node. This means that 
when the access network is the boiiaeneck, network baserl Ibreign Agents are more 
efficient smce there is no extra overhead fbfr tho tunneling on the access network. 

A network based Foreign Agent care-of address is sbarwl between several vislthog 
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mobile nodes. Padc«t6 to tlie Mobile Node ste. intercepted by Hie Howe Agent 
and tunneled to Ih© Foreign Agent in the visited network. Hie Jbxeiisn Agent 
dccapsulsites the packets and foxwarda lihem to the Mobile Node. Since Fbrcign 
Agents can handle many mobile nodes with one caro-of address, r^^wprk 

based rbi«ign Agents does not require the vi&ited network to have & IftriSe IP address 
space made available. 

When using a Co-kiettted care-of address, the; Mobfle Node is associated wjth 
a nnlqiie caro-of address. The Mobile IP tunnel from the Home Agpnt is extended 
and toTTnlnated in the Mobile Nod itself. In this case there \s no need for a l?\>reifipQ 
Agent in the viaited network, which means that the visited network dees not need to 
be Mobile iP aware. Co-located care-of address rcquii^ one uni«iue care-of address 
m the vieited network por visited Mobile Node- 

The two control messages used In Mobife IP are Registration JUauest wid flegis- 
Wfttion Iteply which are sent in UDP pawActs. The Ite^straixon Request message is 
nsed to register the Mobile Node's current cai^-of widre» with its Homo Agent. A 
Registration PUiply i» eent back to the Mobile Node, notifyinfr if the registration was 
successful or not. The control measa^ are described in detail it is necesaary to 
know how ihey are defined in order to uiideretand how the protocol can be extended 
to support IPv4 mobility from 3DPv6 access networka as described in chapter 4. 


3 


Registration ](leqiie9i 

Tho Re^etraiion Request that ia sent fiOm a Mobile Node to the Howie Aijent 
la 6p«<^ed to hold variona addreasea. identification and comtrol bits, a$ ^^'ell as 
exiensiona used for authentication of naers. Tho format of tlje Ru^stiaiiwn Request 
is as shown in figure 34. 



Figure 3.1: Ttic Reg|s|;rataon Request forsnat. 

The Registration Request is sent in «i UDP pack«ft witli a variable source poxl 
and a destination port set to The values used in the Registration Request 
flolda are «po«afied is the KPC as ibllovnf: 

Typii 1 {Uegieiiation Request) 

S S5m<Jhimeou3 bindings. If tlw 'S' bit Js set, tho mobile node \Q r«uue«lnig 

thai the home agent retain its prior mobility bindings. 
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18 CHAPTER 3. MOBIt^iTT BETWE^ 

B Broadcoet datagrams, U the 'B' Isit is set, the mobUe node requests that 

the home agsnt timnsl to It asvy broadcae* datafpranns that it receivea on 
the homa networ):. 

D DccapsvlatSon hy mobile node. If the »D' Wb i» set. the mobile node 

•will ilseir decaptnalate datagrams ^hich are s&A to the caio-of addra«$. 
ThSkl is, the mobile node is using & cfr-locat<id care-of addi>e«w- 

M Mimmal encapsulation. K the 'M' bit is set, the mobile node requests 

that \t9 home agent use sunimal encapsulation for datagrams tunneled 
tci t]w mobile node. 

G GRE oncapsnlatlo^. If the 'G' hit ia set^ the mobile node requesta that 

its home a^nt u$e ORE encapsula*aon for dotagroms tunneled to the 
mobile node. 

r Sent as z«ro; ignored on i««ption. SUOVhD NOT be allocated for any 

other uaea. 
T Reverse IVmneling reqinested. 

x Sent 03 zexo; ignored on reception. 

X#lfe(tlmo = : , - I A 

The number of eecoctids lemainins before the Tcgistratujn is cbwsidered Hxpix^. A 
value of ROTO indicatea arequest for dereglstratldn. A value ofOxm indicaUM infimUy. 

Home Address • y *' . 

The IP addresa of the mobile node. 

Home Agent 

The IP address of the nxojbile node^tf.Ijome agent. 
Care-cf Address 

The IP adiirtsja for the end of the tunnel. 

Identiticption ^ _ . _ , , 

A 64-bi^ number, constructed by the mobile node, used to matchmg RegistratitMi 

Requests with lle^Btratioa Replies, and for prelectinff aEamBt replay attacks of 

rejg^ration massages. 

IBxtentTions 

Tlie iixed portion of the RegistrsUon Keqnast is followed by one or wore ©rten- 
sion. An auth«^5zfttion-enablinff extension MUST be included in all Registration 


Re^Btratlon Keply 

The Roglstracion R^ly sent from the Heme Agenb to the Mobile Nodeis used to 
inform the Mobile Node if the registration wfts suceesaful or not. The format of the 
Keraatration Heqaevt is as shown In figure 3,2. 

TTbe Reffstraxion Rjeply is sent to a UDP packet vrltn floui-re port 434 end a 
destinatiion port set to tl>o ^oiinse port found in the corrospondiiie Kfifi?«U-ation 
Requeat. The values used in the Registration Rep^y iiclchj are specified in the RFC 
as foll<nv»: 

Type 3 (Registration Reply) 
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Code 


Figure 3.2: Tlie KefiteCratioji. Reply fbrmat. 

A vAlue Indicatizii? the r^ult of tlie Risgtoaticoi Elequest- See {MlPv4] 
for rl«t.aj];ti. 


If the Code iield indicates fehat the reglstrAtion was accepted, the Lifetimo fielcl fe 
set to the tiumber of seconds remaining before fehe le^stratlon 13 considered expired. 
A value of zero indicates that the mobile node has bee« derej^Stered. A value of 
OxK&Or indicates infinity. If the Code field indicates tbat the r«i£i»lralion was denied^ 
the CQStedxtsoftfaeLUethiie field core iinspecified imdMUST be iRnored oai reception. 

Home Addir^s 

The IP addxw? oC the mobile node. 

Homo Agexst 

The IP Address of the mobile node*« home aeent. 

Idenii&catlon 

A 64-bTt nuYnber wied for matching Registralion Requests -wliih HegtAtratiOii Kephes. 
Qud ibr protecting ogadoist repliiy attacks of registration messnges. The value i« based 
on the Tdejitiiication field from tbe Regislration Request metRfu^e from Ihe mobile 
node, aaid on the style of replay protection used in the security context between 
the mobile node and its home a^geofc (defined by the molality «ecurilDr association 
between tlxem, and SPl value in the aulhorization-enablSng exCenmon). 

IBxtcnsione 

The fixed portion of the R^cration Reply foiloived by one or more e^rt^Jli^Ion. 
An authorfeation-cnablin^ eactenBioa MUST be included in all Re^stration Replies 
returned by the home agent* 

3.2.2 Mobile 

Mobile TPv6 is based on the concepts of Moldle TPv4, but as Mobile IPv6 1b a pftit of 
the IPv6 tttaadaxd the protocol ie more intcsgrated into IPv6, which mnlcses it possible 
to introduce route optSmrz-atJon- There is no JSbraign Agent in Mobile IPv6, this ia 
due CO new fuActionality inlPvC where U:»v6 N^igrbbor Dimyvery end Address Auto- 
eonfieuration aJlow hosts to operate In «i3y location wrthout any specie eupport. 

Mobile IPv6 esctends IPv6 by int^dvcins uew destinatlpu options to 3Pv6, The 
new options are Binding Update, Binding Admowledgcmeiit ftfid Home Address op- 
tion. 'JClie destination optiona are equivalem; to the reg^ation mcssa^eK of Mobile 
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IPv4, except the Binding Request ami ITome Addrcsa option, lio^^. ^J^,^ 
options are cwrried il> the destinataem options eXte«18ton beadar DPyS, tlw 
^ be piggybacked with any onitgoinff datagram With correct desl«ia*»« »nirte«i 
ofhavingtosendasepaxaieUDP paeifeoc. 

In Mobile IPv6 toute optiiuiaation is a maadaWty part of f^'«?.«'*„ 
respondent nodes have binding caches thtst contoin the owlW* valid blndittB* W»a* 
the node i9 i>^f^. of. Each time a Correspondent Node Is Bboul to W"* » «'«^«^' 
it firal checks if it has a Wading for the destination. If the Undme «»srt, «»» 
attaches a routing header with a sin^e loute Befpneai. to tho dateBram. 
IPvS destinBUon address to tho caro^of address tadic«Mid by the binding andw^ 
the oriEinal deslinalioa ftddross to tho route seement wiHim the k>uUx% 
S^rtWaS^ arrives at tho reoeivtos Mobile Node, the Mob Je Node deiec^ 
tho routing header and 89ad» the packet onward to tl.e address i«acatedm the 
loutl^ beldw. Beca^.se th« addixss is local to the Mobile Node, the « not 

actually sent but looped back to the Mol>He Node, as the destinatioti address is the 

Mobile Node's home addxeSS- „ ^ 

By usinB source rovting and binding caches. Mobile IPv6 ^'towaflio correspon- 
dent nodes to comniiimcate tUiectly HA the inabUe nodes, avrtding triangular loat- 


3;3 Mobility. Between Different Networks 

The problem of liiiiii'aiiiiiB. mobility bet^^ diflferont ai^cess networlto can be 
eoh/ed in a miw.b« of waara.. H we eoncentiabe on the pi-ohlaa described m the 
problem 6taXM>e«tt, .whisre a mobile user want the possibility to BMantam IPv4 mo- 
WBly wlule leanung between IPv4 W;iPv«.,ecces3 netvvoilis. This Ptobl^a can 
bewlJedhy usinTa mechsMiam dcscrt^cd in .chapter 2, called "Dual Stack MobUe 
IPvS" where the MoWle Node reeiateis over IPv'B xroth.the Home Aseut, WW t>y 
nsaie new eietensions .it is possible, to trWKfer I?v4 tvafflc in the iPve ^ 
wdlaa TPve txaffic." TMs solution is quite elegant, ee it. solves the probtern of lFy4 
niohJKty ftow TPv6 ax^esa networla. and it even allows the usor to use ^v€ mobil- 
ny 66 wen. When tba user moves from the IPv6 access network to an IPt4 ac^ 
n^werk, MebUe IPv4 Js used as normal for IPv4 mobility. However, this «»Jetxwa 
has one major drawback, if TPvfl sei-viccs aie used and IPv6 nelworkfi «-e depkqred 
in home networks, this solution would have been perfect, but this currently not 
the case in many networks- Cowpunies that hare invested money m mob>U1y aol^ 
lions for lFv4 and only use n>v4 iy, the home network are nod hkely going to invest 
ev«l more money in in&astraclur« for IPv6 mobility, just to be able to iwe IP/6 
access networks to maintsun IPv4 mobility. It is linJJkely that v^^dors Mobile 
IPv4 solutions are E«nns <» include Mobile IPv6 support in their Mobde IPv4 BOW- 
tions to solve such a problem, as it is going to need a laree Jmplwnfintation effort in 
<»cler to introduce litobile IPvS support. Instead there i6 a need fw a more simple 
solution that can quite easily be inti-oduccd as a port of a Mobile IPv4 sohrtlon at 
a sensible jmpIcmenkaGon cost. This is why the Mobflo IPv4 over iPvQ solutiwa 1»S 
been devdoped during this master thesis. I» does not require the mobile usw to be 
aware of tho network protocol used in the access aelwrk, mad it is relatively easy 
to implenieut for Mobile IP vendors. 

3.3.1 Mobile IPv4 over IPv6 

The woDosed way to solve the probtee of ruumug TPv4 applications when altadied 

to IPv6 access networks is to ext:«Dd MobUe IPv4 with tl» posslblHty to 

over IPv6 The method has been nafoed Mobile IPv4 over IPvS, as il is eiwen!.iaUy 
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Mobile IFV4 thsl 'w traiisported over IPv6. There eactsts & few prearequisitei< in oitler 
to Mobile IFv4 over IPv6: 

1. The Hozae nxiist be configiured with a s^bally routoble IPv8 aMresB, 

2. The IPv6 access network xnvst U5» st atolese or statefiil adOi^ss auto-configuration, 
or possibly 'DHCP76. 

3. T^e Mobilff Node needs to Imow Lfae IFvG addresd cf tlio Home Agent, 

A Mobile Node that is attachdol to aii IPv6 ncteaa nctworlc, can couiigaris ftself with 
Ban IPv6 address UCTg stateless or aUtcful address anto-confignr^tiob, or possMy 
DHCPve. When the Mobile Node notii e tb&t it Sa attached to cm IPv6 network, it 
senda & Mobllo irv4 Registration lleqiiei^ in an IPv6 UDP datagram 10 the 7Pv6 
address of tlie Home Agent. The Home Agent eeUi up IPvs tunneUng towards (he 
Mobile Node and fiends a Regtstration Reply back to the Mobile T7ode. Foe tins 
to 'work, a nev Mobile IPv4 CKteitslon noeds to bo d^zzad thai cm stoiA tlic IPv6 
Caro-of address of the Mobile Node as tho cere-of address fiiBSd in the R^istrAtfoD 
Request is too smailL This eoctsnnon is attached to the Registration Request tlmi 
id $ent to fch« Hovno Agent. 

This sohitton will oilovtr the mol^ user Go run IPy4 amp^llcattoxis whUe attached 
to an IPvG acce^A netwoYk. It even allows the Mobile*ZPv4 neer to seamlCGsly roam 
between IPv4 and TPv6 acoisss networks, which 'means that a njobU^ user that Is 
jmmins IPv4 applicaUond do^ woz need to bo awavo of the Inteznefi protonol \vsstd 
in the access network. The Mobile IPv4 over IPv6 eolntlon fs described in detail 
In chapter 4, said the hnplemenialioa of thits eolation performed daring the mastoir 
tfaosls is doacrlbod in chapter 5. - ^ 

3.3.2 IPv6 over Mobile IPv4 

Mobile IPv4 over IPvS solved the situation when the home network of a mobile 
user is rmming IPv4 axid the mobile user wants to run IPv4 applications^ while 
beSng away ftcmt the home network. Ji the home network is running IPv6, Mobfio 
XPv€ can be us«d to allow the mobile nscr to nm IPvS applications, biit Mobile 
IPv6 can only be used when attached to an IPv6 accos network. If the vmr is 
attached to an IPv4 acce^ n^ftwork, MoblloiPve services won't Ise available. One 
solution xo solve thib- ie to nee TPve ovoi' Mobile IPv4, as specified hi pnal-MlPv4]. 
Tbi4> requires that the home network is ilvaJ «tai^ a^ the ro^j^stration is done u^g 
the IPv4 home address for the MobUc user. The registratfon request is extended 
With an lifV6 addxei^ extension wluch the Mobile Node Caa use to request usage 
of the IPv6 home address, or an assigned dynamic IPv6 address. The Homo Agjcsnt 
responds with a registration reply -where the IPv6 address estlen^on contains the 
IFva addrees use. 


3.4 The Complete Mobility Solution 

If the home network of a mobile user is running JPv4 and IPvO services on the same 
network, mobile users will need to be dual stack configured. In order to reach all 
servicea in the mixed environment of the home network, while outside the prt^mific^ 
and away from the home networki a complete m.obil2ty solution for IPv4 and IPv6 
mobility needs to be set tip. 
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3.4.1 Combined Mobile IPv4 and Mobile JFv6 Solution 

By combining the nictlstids d)scvssetl in Ihw thesis, il is possible to set jxp acompaete 
solution for irv4 and IPv6 mobaity. In this enviromnenfe, Mobile Nodess will baye 
to be dnal alack add Homes Agents far Mobile IPv4 and IPv6 hajs to be set wp m 
tho home nei«/ork. When the mobile user moves out from the corpoTate prern)*^ 
md connect %o aa access network, via a cellular phoYie service, wireltjsa LAN or 
LAN for inetance* the user should be able to register -witli ita Home Afgeni, other 
via IPv4, IPv6 or both In order to fidjieve mobility for both IPv4 and IPv6. There 
are a nimiboT of different waye the mobile nser can achieve mobility depending on 
the type of mscetaj network used. By combining the mochanlsms in in figiite 3-a in 
different ways, IPv4 md J(Pv6 mobility can be achieved from any aece^fi wecwrk. 



Figure 3.3: Table showing the mechanisms used for a comKncd environment. 

The table in figure 3,4 illuatr&ie» the posable types of attaximent to access 
neowrlis, and whfch of the. mechanisms .that. ean.bA combined to achieve mobilily 
in these access networks- • , 



Pigure 3.4: Mobility £cam all access xtetwcirlu;. 

As can bo seen in the table in figUKS 3.4, there are fcw» -waya to achSffve mobility 
for IPv4 when attached to an IPv6 access network. One ia IPv4 over MU'v6, but 
as thM requires a ftill Mobile IPv6 implementation as well as. TPv^ over MobUe IPv6 
impletrtentcaion in the Mobflc Node and Home Ag^. The Mobile IPv4 over IPv6 
mMhaniam ihat has been developed durmg this master thesis has 
take advaiitage of the currently available imptementations of Mobde 3Pv4. tYom 
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a duni stack iu:c«s^ network^ there are Trtimetoud ways to achieve IPv4 and IPv6 
mobUity, but Ihe most attractive of them ia probably to use Mbbilcr TPv4 aiiJ Mobile 
IPv6 sepwately as this altows the uae ol separate mobility sohitSoji^ for IPv4 and 
IPv6, On the other hand, \t «etsi hand cfver times ere eeseuiaaL, for voice owsr TP 
UBage Ibr instance, a combined eoliition that onJy reqmrea one zegpstration miglit 
be moro att>tL«!Civ». 

3.4.2 Deplpsonent Scenarios 

Tl» Mobile IPv4 over IPv6 solution can be deployed ^ shown in figure 3.5 where 
t^he Home Agent Is aceeasible frcan the IPv4 and IPv6 Internet. A deployment like 
this adlow mobllo i\ode8 to eecuiely aiscess TPv4 eerwiccs in the home netwotlc From 
IPv4 and IPv6 exsxsQ networks. 



Figure 3-5: Mobile IPv4 over IPv6 deployment scenario. 

The complete mobility solution for IPv4 and iPve can be deployed as sho^jra in 
fiffuro 3.6. In this deplcQrmcnt scenario Mobile IPv4 and the dual stack mobile IPv4 
BOlutlon [I>ual-MIPv4l, la used when the Mobile Node ifi located on an IPv4 acraw 
network. When the Mobile Node ia located on an IPv6 access network, Mobile IPv6 
IS ueed together with T.he dual stack mobile JPv6 solution Pusa-MIPv6l. 
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CHAPTERS, MOBHJiy' B£ITWEEN IPV4 AJm IPVe NEO^^ 


mil 



FigEure S.C: Dcplttyment ecenazio for ono of the pOfiSibte combined mobmt^ solutioiia 
£br IFv4 and TPv6 mobility £rom any access network. 
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Chapter 4 

Mobile IPv4 over IPv6 

4.1 Backgroixiid 

The cominer<dsa use of IPv6 is very llmltod today mcetly due to the of ««ppoTl 
for IPv6 ia coimnercSal appUcattons. Fov this x^^sm n>v6 wiH inosi likely fiust be 
deployed in access networks and operator backbones, SsA infitfuice a ceUtdar phone 
service lunning on IPv6. Therefore » new Mobile IPv4 escteMion end method to 
use Mobile WvA over EPvO iwtwoilffl has been developed, which allow mobile iisewi 
to conmect to their IPv4 hoane n^work in a secure way, while seamlessly rownuriK 
befcwxsen IPv4 and JPv6 eccess networks. 

4.2 . Extending Mobile IPv4 witli tPv6 

Functionality 

4.2.1 Overview 

In order for the Mobile Node to be able lo register Co-Located with the Hoivio Agetit 
over IPv6, the Home Agent has to be configuTcd with a globaJly lout^ble IPv6 
address and uhe Mobile Node has to acquire an TPvB care-of tulclress. Whna thwe 
conditione are met, the Mobile Node csm rcpater Co-I.oc*ted ov«r H>v6, bvt Ihe 
Home Agent hna to be able to obtain the caro-of address of the M^bUe Node- It; w not 
sufficient for the Ilome Agenb to obtain tlie caie^f address by looking 9^ the source 
address In the Be^-traxion Request since the packet could have been iiiauipu lated on 
the way to ihe Home Aaent by a man-in-tho-middle attack. Instead it is necessary 
to define a new extension to the Registration Reqne&t; to iranfiport the oaj^of 
flddre$5 of the MobUe Node. This new extension can then be secured by the RIN-H A 
Authentication Extension at the end of the Jtegistration Kcquest. It la therefore 
important that T;he new extenmon is located before the MN-IIA AulheiiUcaticm 
Extension hi the Registration Request. Wlien the Home Agent has acquired the 
caro-of Addre«j of the Moli^e Node and mithenticated the Mobile Node, it can act 
up an IPv6 tunnel towards the UoW^ Node instead of the normal IPv4 tunnol. 
X^ing this method avojds the use of double tunnels, which would be tlic c»se if 
Mobile IPv4 wafs to be tunneled inside an IPvfl tuwnel. The method ol uhsiug a 
Bin^e IPv4 in IPv6 tmmel significantly decreases the overhead. 

4.3.2 Deployment Scenario 

When ii^ng Mobile IPv4 with the new extension, the mohilo node can seamlese^y 
roam between the different access netwoi ks as Rhown in figure 4.1 . If the mobile node 

2S 


•3 


•1.1 
> - . 
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ia collected to Da IPv6 access network, the inobil* node wUl coiifigMr« itself 

C«W AddiBBB. udBB for instance Ste1fe« Add«= A«t^c««figu^ 
IKFC24621. Tho mobile node cwi thm register oo.tocate.1 ««r IPv6 wlh Uie Home 

?hte require* thk«« Ho«e Ag^nt is configure a globJly .^^t*^,^ 
address Section 4.3 d8«rib« tho detafls of the «ctenaoa ii«a m. cxvtocated 

rcsgistration over IPv6, 



Hgure 4.1; Deploorfa^ m«»b«o wlvB«:.tbe new;;b^;^n to MobUo Wvi can bo 
'useful. . • , .- ■ • • 

It is possible that the jiovida: of the iPv6 wa^esa^ nefc^wrlc 13 aspJi^e i« 

thiougU a NAT-PT router cm also be supported If tlie Mob?«,^"=^»"^ ™T 
Agei^ls capable ofNAPT trKven«l IKFC3519]. Sootioo 4-3.3 'i^^^^.^'^^' 
Slo node cau reenter «hcoi«> » JVO^VT s^^- W tho 
nocted to a pure IPv4 network, the MoWle Node opep«t«i ea nomial wlthont the 
new c9ct«nsion. 

4.3 Bxte»»oii Details 

4.3.1 XPvG Car^tctf Address SbcfcendoEL 

The new extension to Mobile IPv4 th»» i« «ed to tturrythe IPv6 «re-of addrM. 

of the Mobile Node is i.«ned "IPv8 Oate^of Addvese BctwiBon" 

If the IPv6 C3are-of Addresa ISxtm^n ia uSed, the Wta of 

fidd in the aegiBtration Reque« header drmsc b« set to «ero.^e Care-oT 

Address ExteJon ahoiid be attached to the B«ffB*rt^ 

HA Authentication EsctenMon so that 16 ia secured from inM>riD-«i<*-««»ddIo attaoKs. 



Figure 4.2: ftarmal of Uie Critical Vendor Spodllc Extension. 
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4.3. SXTBNSION nErnAILS ^ 

The IPv6 Cate-of Address «xteiUiIon a Crttlcal VOTdoi/Orpn5»^ Spedflc 
iSxtemion (CVSE) IRFOSllS) dtoptayed in figw 4^- B«K«» "* 
Criiiic&l Vendor Specific ExtenMon described. 

Typo CVSB-TYPB-NUMBBR 38 

Reserved Beaerved torfiitiireiise. Mt7ST be sa* to ODllBaldiIlg,^^JST bo Ignored 

cm reception. 

I^ensth Length in iQrtes of this extension, not indudhss tbft Ty3?c and t^sngth 

\ J 

T^hiSj^SSS^StsA is 0 and the" lowworder 3 octets axe the SMI NetworTc Manogp- 
iniei^t Private T3«ten>Hae CJode of the Vendor in network l»tB order, as defined In 
ihe Aissigned l^inubere BPC. 

2^2S^^SSSL *ype ol Veador-CVS]&.act«ifiioa. Tho ^ndntetratlon of 
the Vcndor-OVSE-Tiypes X9 done by ilie Vendor. 

VeiidoiP-CVSB- Value' . tr j 

Vendor/organisation specific dafcDL of this Vendor^V^ The Vendor- • • v • 

th« lAjngth ITteltl VaJii*. ' ' ■ 

IT the receiver does not recogmze the extension, the entke packet is to be ^eJi^ly 
dropped The IPv6 Caio-of -Address Exteaosion has tlie' length, field set to ZZ and 

the yendor-CVSR-Viilue must he set to tjie JSa-bit IPvG caro-of address assigned • '« . 

to the Mbbik: Tar<>do. 

4.3.2 Co-Iiocated registrafcion over IPv6 

When the MoWIt* Node is located an (m IPvO access network and has arqulxcd an 
TPv6 addre83, it can register Co-Located with the Home Agent. 

Mobile I^ode Actions 

The Mobile Nodo has to be aware of tho etobaJJy loutable JPv6 address of tho Homo 
Asent. Whcm tho Mobile Node notice that jt ib connected to »n TTV6 network and 
hwlonfisiired a xmlque IPv6 «Wrws. U will try to eend a JlegiCTmioii rt^nvest 
with the new IPv6 Owen^f Address Extension towaards whe IPv6 addrwB of the 
Hme Afienc. When a •'resifrtrefcioii accepted^-reply is received from the Honie 
Agent, the Mobile Node can set np an IPv6 tnnncl towards the Home A^- AJl 
^ iaffic generated by the Mobile Kode will bo cncapsnULtod in the IPvC tunnel 
and sent towards the Home Agent. 

Home Aeent Actions 

If the Home Agent is confiffuied with a globally rentable IPvG addre^it ^^l^^Eten 
u> VDP port 434 ov«r 3Pv6. When jl T6Agi«tr^,tlon Ke<iuest J» r«CM?Jved, the Home 
Afipnt checks if the TPv6 Car^of Address 33xten6ion is pr«$ent; in ^'^JJ 
Request, jf tJiiU is TjHe ca$e then rJie csxe-of addre^ lield muift be z^. *^ ^^'^.t**^ 
field i« not .et to 7.ero, the Hc^me Agent ^1 s^d a "reg^^^tion denied 
Registration Beply to the Home Agent, and not aHow the Mobde Node to «e^sto 
On the other hand. If the cate-of address field 5a set to «Bro, the Home Agent will 
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authenticate the Mobile Node as usual. I£ the authentication KSttccesaTul, the Home 
Agem will fltft up an IPv6 tunnel towAvda the IPv6 caieof oddrras found m the 
IPv6 C«i^of Addresa Extension. Finally the Home Afinnt isrtll send a 'registration 
accepted" Re^ration Reply to the Mobile Node. 

4.3.3 Co-Iiocat©d Registration aver IPv6 Through NAT-PT 

IX the pro\'ider of the IPv6 acceass network is supplying iLb ciHStomer* wjtli ^ NAT- 
PT ns"AT-PT] service, it is not necessary to confisaie Uie Home ABOTi»_wilh a 
globally routabl© iPve address, since the fitegisCratlon Heciuwt cent over JPv6 can 
be translafced by the KAT.PT gateway and sen* over IPv4 to the Home Agenb- 
This however require thab the MoWle Node does a DNS lookup of the domain name 
of the Home Agent, and not use the IP address dhectly. If the access network is 
oonfisured with a NAT*PT gatew, the DNS loofcap vill return the IPv6 aadrj^ 
of the Bomo Ag«iDt the dovnoin name, md tbft Homo Agent, is oonflgurod 
a globally roiAable JPvfl address, tn tliis case the reaistratjon proccdnro will Ije 
tSxojMy the same as in section 4-3.2. On the other hand, if the domain name, and 
the Home AgOTt are only configured with a gtohaMy routable IPv4 addresB. the 
DNS lookup wiU return a feked IPv6 address with the IFv4 address embed^ 
When the Registration Request is sent towards ibaa feked IPv6 oddreas, 
is translated In the NAT-PT gateway and sent towards the IPv4 address embedded 
m the IPv6 address the.Re^stration Request-waasent to. 

Fbr aU this td woifc;"the Mobllo Node Homo Agftnt has to suppon NAPT 
traversal (KPCSSlsj- This moans that whem the Ho)l»e Ageiit receives the Rcgisrtra- 
tion Reouest It chedcs if the addredM in the care-oT addrewj Tieia in the TLegiatrAtjon 
Request IS diffewirt than that vftte source addrefe in the IP be«4er. When vsed 
tdfiether with the v6 Care-of Address Bxt«Mlbn; the Care-of Address field m the 
ReEistration Request is set to zero, thus it Sa dIffariHit thaai the address in the sowce 
address field in the IP hqader. TWs moans that NAT traversal should bo activated 
and all traffic should be OOP encajjsul^ited. 
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Durinffthia master tliesis, Mobile IPv4 over lT>v6 wasirapleineiitediiiipTJjxpnigged'iJ 
mobility sohittoxi. The eolution consist at three products: 

1. RoomiBg Gateway - Acts as a Homo Agent and Ebnreisii Agent in a iifitvrork. 

2. RoaanlY^g Cljenl. - l^e . Mobile NocJe implementation on Microsoft Windows . 
2000/XP, lo be installed on cvijry mobile dovlcs the* uee<te mobililar, , • • 

3. Roaming Server - A wb-based central xaansesment eennsr used for c'enlral 
-user and coinfigiilDdtion management. 

Ab Mobile IP does not define how to aecme the traffic, m addibiooal security mcciv 
anism |8 needed. IpUnpliifiged hes diosen to use IPtec inrfdc the Mobile IP tunne* 
to sccim the (xaffic. 

5.2 Goals ^ 

The goals ol the implementation was to get a ^irldng prototype that could demoii- 
strate how IPv4 mobility, secured with BPscc, could be maintained white niammg 
between XPv4 and IPv6 access nefewoTks. A$ the impXementatton was to be done by 
one perwm the project had to be demorcatftd to oiOy mdudo the necessary func- 

tionaHty in order zo get a >vojldng prototyi>e. Ebr this protolgpe cJiaacee had to ^ 
be mode in the Roamms Gatew^ and the TUamhig Olient. The TloAjuing Serv^ . J 

is not needed for this prototype as the cofifisuratiGn of the Uoaiajng Gateway amd 
Client it} assumed to be done maanaUy. 

5.2.1 Home Agenrt 

The IbUowing nie the goaJs set up the runctionalfty of the Horn© Agent (Roaming 
Gateway) implementation; 

1. The Home Agent has to be extended to Ijandle Reffstration Rcqucsi* over 
IPv6. 

2. The Home Agent has to be able to send Ragtetratlon UepJiw U> the Mobile 
Nude over IPv6. 

3. The Home A^t has to handle (Oie new IPv6 Cor©K)f Address BsctenHion hi 
Re^rataon JRequests. 
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4. The Home Agent has to t« able to decapsulaxe TPvO tunneled IPv4 pftctots 
from the Mobile Node. 

5. The Home Aflant has to be able to encajpflalatc IPv4 piiebeta in tlio IIMJ 

txmnel. 

All of the »bove goal* has to met in order for the Mobite IPv4 ovor IPv6 soluUcMi 
to -nork conectly. 

5.2.2 Mobile Node 

Fbr a working hnplemeirtatioD of Uhe Mobile IPv4 ever IPv6 soltl«Mi Uie ^tob5Je 
Sde StoSs ai^) has to he exteaded with the frllc^^lng lunc*ioi«Jily: 

1. Th« Mobile Node has to be able to receive loiiler ''^^'''^^'^^''^^J^^ 

infomatlon, in order to configure the IPv6 to use. The IPv6 ^d««S 

^ lo be t4n6s»»~d "staS *ho rtatdese eddieee «ilo^«ft«».tAtton method 
[1EUK;246S(|. 

. 2. Tho Mobile Node,haa to be able to.«nd I^gtat-ratipn RoqufiSte <wa IPv6, 
usine the confignied IPv6 addiees as aprnicp.adclresa, ^^™* 
IPvB w^Irit-ftaa.as destinatipin address. . , . ■ 

3. Tlielil<*itel<rodehMtobeaMeto inciidetheiPv€Ci««-ef AddJ^Fxtciiaioii 
in titeUegist^ation Request. - • 

4. The Mobile N94ei has to be able to'tuund IPv4- pe|4fite 5ir IPv6 headers, 
dostlncd for tha Homo^A^snt. 


«. The MoMIe Nodte hw to be able lo dec»pBuls(» IPvO timneled IPv4 packets 
from the Home AEent. 

B. The Mobile Nodo has to bo ablo spBt tiumd IPv6 traJEc, i.e. IPv6 traffic 
should b<i sent directly out on th« taterfeco iu»d not timneled lo Ihe Ilome 
Ageiit. TIUS aOows the use of IPv6 servicas at tho some tome as IPv4 mobility 
is \vsgil Irom an IPvO ftcce» network- 
In OBder to vse Mobile IPv4 over IPv6 without the need to install thcilPvfi stadc 
in Mcrosoft Wiadows 2000/XP. addaBooal Boato have «P 
implementation. 

I. The Mobile Node should be able to notiftr the netvroit interfa<e *^ 
reeedvethc necessary mnlticoat tinlfic in order to recewe router eOversisements 
and neighbor soUcitatlonB. This Is something that the IP ^6 dnver 
dooe, bit as IPv6 win not be Installed, the Mobile Node's Mobile IP driver 
has to do it. 

2 The Mobile Node should be able to leapond to neighbor fsoUdlsltoiB. In 
or*tei- for the Mobile Node to behave as an IPv6 node among J^^^^^f!^ 
•tUo noiwork, the MobUo Node should ftilly support Neighbor Dtocovary, bt* 
for a minimal prototype implementation it is encash to '^'J!! M^r^?rf«^ 
solicitations. Neighbor soUcitations are sort as a qiieiyw<5et'*« MAC addrM 
^ihe node, if til Mobile Node does not remand t.. U.«e soh«ta.ta«..s ^ 
p!Xhs lioii the IPv6 router in Uie network ca>m«t be sent to the Mobile 
Nc3cle. 
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S.3. TAAC^T PL/OFORMS 
B.2.3 Solution 

Coinfaimiig aU features spedfisd in the «.T>ftv« jjoals f&r the HomeAgent '«>d Mo- 
bile Nodte win result in a spluticm thai «lto«B a oiobfle .««r to ertffv4 ™ob.hty 
^d«»>«utcnt of tho Interaet pzofcoebl used in ia» iioce« nelviuHj. Tr> enhance the 
wSK^an «»»o. tho mol^ ^ m.^ not own have to inatall IPv« » order to 
use MobUe IPv4 <wer JPvS. 

5.3 Target Platforms 

The Boemhitf CHt«w«y ie based on Opoi>BSD, wbei-e tho MobUo IP fimctlonaM^ fe 

B^te^^^m 0/0+ ^ j^pj^^^^ software »i»plit;atIon o» Wwdows 
2000/XP, using a low lerol miniport driver for network commiamoatwn, a Wm*rw» 

acrliiefor Mobile TP operations and a control applicatioii. DurtoR the iifj^"^ ^ 
ol the «li«nt vWAittl interface te Jnfitai).«l that coojjmroicatea with ^ ^'^^Z 
^t,^ as the home inl^fece, configured *-ith the home IP C-Wr^ "^^JZ' ^ 
inakes sure that when the moWle user moves from the home aelWoAwv^^ 

different acce«» network, ths higher level apphoaUOTS w, 1 not bo 
IP addiesa chanee. The miniport driver is developed in G and tJifi Window*. *«tvi« 
• aaid oonlzol applicalion are «|evelcped in-OH-. • • _ * " 

' ' ' . * . 1- • ■ ' . • 

5.4 iaonie Ae&at 
5,4.1 Overview. 

ThoRoawlng Gateway JsipUnpliJgeed'emobnttyWttterv^fthHomo " . • 

cigo Ag^=nt fimctionHiily. As tho Mobilr^ TPvd over IPv6 solutson onljr ibo ""^ 
Aient. The B^reien Agent does not uee.l to be extended wrth "e^*^""^*'??^ 
a Home Agent implementMion oou^ ol two parts, one ;««>>-p»w Mob.l« IP dao- 
4on and mJw.U TP rorwardio«/t«nneline in th« kernel- The. to lowmg «>^«»>t^*l 

f<,otn<M have U> be hidwdwl in onJer ».r Uw Boamiug Gateway «..i.iii.rt TWoTmIo ) 
TPyl i>vw 1P«6: 

1. Tho Mobllo IP daemon has to MXCfA Jncomtog Bft«IStra«on ne^fuosts on -UOT 
port 434 over TPvti. 

2. The Mobile IP daemon has to bo able to pnn out tho CBK«f address firom . ^ 
the new TPv6 Caw-of Address Eirteiision. 

8. The data structiaea used in the Mobile IP daemon has to be esctend^d to 
support both TPv»J and XPv« addresww- 

4. The Mobile IP daemon has to b« able to send »oeiBtr««on B«p£is ovw IPv6 
to Mobilf! 'Nodes. 

5. The communication channel bctw^^n the Mobile IP dftemoft and the Icerwrf 
has to bo cxtiiiided to support both IPv4 and JPv© oddresses- 

6. Tho kernel lias to be able to set up tunneling «rf teaffl* eenl to the h«n» JP 
address of the MoWte Node to the unrrant caie-of adonsss of the Mo)nle NchIb. 

7. The tosmel has to bo able to encapsulate IPv4 packets to tte honie ad^ess of 
Uie Mobile Node to IPv6 and send them to tho care^f address of tho Moblte 


Node. 
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8. The kernel has to be abte to <J»»psuWe JPvfl timneled IPv4 i»^lccte from tlio 
MobUe Node. 

S.4.2 Userspace 

The iiist parv lo be ext^ded with MobUa IPv4 oviar IPv6 ^^"'^^•^"^If ^^^^^ 
Mobae IP daemon, as it could esslly be tested by a small Program that can send 
■RfiMstratlcm Rcqucfrts over IPv6 lo vcrUy the new ftmctionali^ The Mobile IP 
da^oa iiomaJV i^capt incoming Iteration B«qu^t^*>^' Y^L^^^/^ivT^ 
IPv4, Thy daejiion has been extended to listen on UDP port 4.i4 over IPv6 as 
veil, tor reception of Re^istttiiaon Uequeats sent over IPv6. AD d^ta «tr»ictiv«s Jn 
the Mobile IP daemon that hold» IP addressee used \n the Home A^b brndrng, 
such as caue-of xddxees. Home A&^t w3dres« etc, bavc been extended to Bti^ort 
both IPv4 and IPv6 addresBes. The c.lata ytractiiree vsariables of ! 
sochaddr Btructs to Btor© iPv4 addns&w, but in order to support both IPv4 ^d lFv6 
addresses, the socteiddr^lorage atnirt had to be iised, which is specificiUly designed 
to be protocol independent.. This however required ^julw oxtenslv© changes in the 
old code as these data stiucbnres are vsed extensively throughout the code. 

Tlje care-of addi-esa of a Mobile Node that registers over IPv6 retrieved Iiom 
the EPv6 Cere-of Address. ExteuMow in the RestBtration Request. When a Mobfle 
Node registers over IPv6, and the IPv6 Care-of Addre^r .Extension is not pT«e^ 
m the Registration Reqtwast.. the Mobile dNode.is nt>t cUlP^.ed to register. If the 
(sctenslon Is avalTablo-daa the care^f addroes^fleld is set to'iaero, the vtrer cwi hi? 
authonticatcd and the rotation will be accepted. The Mobile IP daemon then 
transfe«j the bhiding infoiwatlon to the kernel to act up Mobile IF timneling. The 
comjnmiication channel between the daemon and the kerneT ytt^ be«Ti fixl.Riiderl to 
support both.irv4 and IPv6 addresses that aro ttoed in the bindmg mlumiation- 

5.4»3 Kernel • 

When the usertpsce impIbment»t|oii w»s done, the l^^riiel part of the MoMe 
implementaniuo vras extended with the necessary functionality. Tho Mobile code 
in the Isemel that set up Mobile IP tunneling according to the mronii»tiOJi retrJ«yed 
from the Mobile IP daemon, had to be tended to set op IPv4 m IPv6 iuxineim^ 
As the Roaming Gateway is based on OpenBSD, most of the necessary code for v4 
in IPv6 tunnolinir was already avaJlablo and conld be enabled by usmg the IWIST6 
compile option. This made the impkanontation in the kernel pretty straightforward 
as the IPv6 codo in the hemel is orgonisxsd in the same way as for IPv4. 

5.4-4 Testing and Debugging 

The eactendcd functionality in tho "Home As^xjt was vsniicd by a small program 
that caas send faked Registration rUsqnesta over IPv6 to the Home Agoot. It was 
wxessiLry to write this «in»ll test pn w^wn ss U w«© folr. tu be advantagooos to have 
a worWn^ impiemontatioa on the Home A«eat before H«y work w^ starred on tho 
Mobile Node implementation. It was verified that the Mobile IP daranon panred tliO 
IteriBtration Request correctly and found the new IPv6 Care-of Address Extension. 
The daemon sent the binding information down to thelcowfiel and it conld bf verified 
that IPv4 in IPv6 tunnoHng was eet up correctly. The actual tunneling of pa^ets 
conld be verified by sending packets to the home address of the Mobile Node frona 
anoi^hercompuler. VJBineEth^el [Bthereall, thetimneled pai^ 
and verified as sent on the outgoing IPvO network. Tt was howcvci- not wified Uiat 
the hemcl dccapsulatod incoming tunneled pacKeta ftom the Mobile Node correctly 
es this required to much worli to vcsrift^ at this stage. No special debuggmg tools 
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wertiused to debug the Mobile IP dnemaa. but kernd core dumps wne used to d^bug 
the honel SmplraienCa'Qon- 

S.4.B Conclusion 

The tnmtementatlon of the new Home Aeont ruBCticowJity was ttou^ ^f}^ 
iXTSTrf So MobUe IPv4 over IPv6 imptemeot^tion. Tl^^^^F^,^^^ 
!Z^«rth« imnlemcntation orfy to«>k about -5 creeks to complete. Aa tastaMaUon 

WW jXllIng th* sy^ from the CD. the necessary IPv6 er.^ ed Q 
Bne 3ppliCAtJ««« tocludod which aie needed dnrag config..m.ou of 
tha ByBtem, 

5.5 Mobile Node ry 
5.5.1 Ov©3rvil«w 

The RoamiiiS Client whieb Is ipUjiplogged's MoMIe Nodo implementation is di- 

W i^Jpoit drtw*, ftMobile IP Wftid«ws service, a 
^^SpeS^ «d 1 network adapter. Th« » Wpoxt driver mt«r=^ 

?^ ffld decrypt tunneted pswdcets which then are sent to the virtual adapt^. 
^^vee^^ary also a«««w ARP requests and send 

nfi^^»tIOtt lUipHce aad router ad^teem^mts Utf to the Mobile IP servicft. The 
SSSr^"^ ttS to be induded in the Boanrfng- Client to sopport Mobile 
IPv4 over IPv6: 

1. The driver has to ittt^K^ iucouuug IPv6 i>actec£. 

2 The driver has to veetete' plKy*U!«l interfow twjco -sinth the intraoept 
SJy? Th« .«t.rcGSm>«*y vrm then believe that. th«ne ^^.^^^^^^^ 

lows ir.depftnd«nt opetatlou rfthe V»m faiterfoces wxtbin the Motato ^^^^ 
wMeh h«a.lte the ^6 iuwrlaw jMM Bbe any other ii««r«eice oerd connected 
ta thft computer. 

a. The driver has to ddiv«« tl»o »olom»t TPv6 peckets to thft intercept lihraiy «or 
further proceasnng. 

4. The intercept libi-ao' baa to be H,T:>le to reeo|fni» router adverttaemcma and 

send theni up to the Mobile IP service, 
a. The Intercopt libt*ry has t» be W recogniw n«iehbor solicitations and 

send them op to the Mobile IP service. 
6 The intercept library has to be able to Tecogniaw Mobfle IP IteBistrixtioji 

ijjlte Sever IPv6 and sond them up to the Mobile IP eorvlce. 
r. The Mobile IP service has to be able to eonBguro the IPv6 Care^ addrws. 

usiiie the prefix receHvcd in router advertiBemenhJ. 
8 The Mobile IP service has xo be able to compose Jtegiatration RoqpjiMtg with 

^IPv6 header tostoad of TPv4, to be «ent down to the driver for delivery. 
B. Tbio MobUe IP service has to be able to compose Neighbor Advertteements to 

send to at>licit«iine nodes. 
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10. Tho control appUcation has W be able to piw«» tjia «^«?*>y 

Cer^f addi-ek and IPv6 addiess of tha Homo AfiiMK Ibr t1i« to 
configwa-tioa difiJog -whefxi Co-locatod on TPv6. 

5.5.2 Driver 

When anew teterfac« la coimected U, ih^^wv^f^ 

Bbtarv of tho new toeifeco. However, for each P»«W^ ^TL^^ 
track of two dltfoT«« ld«rtttJes. one for rewption off IPv4 p«K*0te *'»»J^'^;^ 
padcrts. The driver mforms the intercept Hbraiy that * 
to3> Physical Jrtcrfai^c, nang these two Id^ntHS^ Tim alIo«B the txw virtnaj 
intcrfiu:^ to b* treated separsitely in the iuterc^ liteaiy. 

lb be able to iotexcept IPv6 p^-J«.t9 the d^'er h"* ™t"l^G ^^V^- 
receive router advertSsemeirtB and neighbor sohcitatiojiB- Tf tho TPvG st^is 
Sd Windows wai make sure that the neceasaiy muliicasC MAC mldwssxs. 
'to ihc ^ticast addr«s li* in the 
network intovfaoe previoosly has been oonnected to on "^''^T^^ 
later cortn^^d to an IPv6 network, Windowa doea not se^ to add P^"^?^ 
mSti^t MAC addT««8 to tha addwaa Bat. The MAC addr*^ are «;dd«l to the 
Sr^U^aSar a tSmeoot that ca». W « teau « »> wconds. which makes 
tam^M times from aa IPv4 network lo an iPvRnetwork tettftly ^ow Thte 
ir^h^d to^te»Sthe Mobfla-lP driver, add the ^'^^y,^^}'^'^ 
t^^S^Itet TOs Hjai also allow of the Ijtfobite .JPv4- ovar IPvC mw*i9^ 
^iS^^^ «a*S«t=U«i in Wtadowa. By havtag the driver «W tba 
^^m, malticast addresses to the address list, theiand-orvet tmes was xedW 
^ rt^»n onl saco^d. Whan an IPv6 pad«t ia ISJl^f?*"^!*^^ ^ 
. padcat to the Intereapt lSt»«y togpthcr wftli the IPvfi l*«tHy of the iaterfSce the 
padcat waa iwceived ooa. , 1 . ^ ... •. 

InlarcDpt Iiibrary 

Ito intercept Ubraiy 3b a part of the driver, and it >?>ake6 a de«aon whether to 
inoomhig padcets furthar, leave them to the ^indov^lPv-l/IP^a^ 
delete them. V>^1^ tl,at ^ p^cessad fUrthar can 

^n^i^utcr ^vartiaemants. tha intercept Ubraiy If^'^tff 2^!^^ 
^T^cka if thoTO Sa any prciix info«nat5o« available « «^ '"'^T.^^^^X 
^nt^pteJix infbnnatlon, tho ia a«tt np to the Mobda ^J^^J^' 

^^rocM^ng WaghboT solicitationa and Begisfcration R^bas «e also sm*^ 
^S^pl^«r T^xm^ l«^«t^ rn«n th^ Homa Agent ara docapauUtod, 
daeryptad and cect up to the virtua) a;.Uipter. 4.l 
intercept library also handte outgoing packata Whan im IPv4 pa^ to 
«mt too tha vwual adapter, the intercept libraty^akea a«ra ^^^^ 
fflj^tad and encapsulated in anlPvfi or IPv4 packet, depetndmg on the avrranay 
used Caia-or addxass, for delivexy lo the Home Aseaft. 

5.S.3 Mobile IP sisrvic© 

The Mobile IP service ia started when the ooncwd application to ^"^r ^^'^^^T^ 
l^S^ decision making proc«3e» auch aa wMdl ^^^^'Z^^^'^.J^'^'^ 
nctworits are awaflable. when and where to send H«g»trafcion RcquwW ""-^^ 

M^ba* IP aarrfce baa been extended to handle 1Pt6 Interfiurea. When «q 
IPvI^of aXss can be configured <m an IPvfi lnh«««e. ^.^^^^ 
Wnpoae and sand out a ReRistratlon He«ines1i to the Home Agent over lPv« 
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wii h the new IPv6 C«*-of Address Extension ottechfid. The letnwtog R<^-a«oft 
to «p tuaneBng lawwte th« Homo Agont aiid IPsoc «i>«yPl»<m «rtta ft^- 

Xhbor advertlBamente to the soUcUalinS nodes. This is "f^""**"* 
SXbeL done effldant directly to the dilv^ bo9»8v« »ot Am d™» 

to tone wii*tr«i«ts «» it vras easier to compose n«gHbar «)hcit«t«aB in tl» Mob,te 
IP Bemice. 

5.5.4 Control Applicatioii 

The control appltaatloa la used to enable and dteahte tite 

iXmktloii, hSdlo network adapter priortttoa et*. Tto control *PPHcatl«xj^ 

^3od with the possibility to shov the camni^ «sod IPv6 C^e-o£ 

™Ster«d Co-loca-ted on IPvO, and the IPv6 address of the Honie Agent m the 

;;«S^t5S^r^or**sb^inW5.iatisato possible t*g^ 

m ics^. Tor example whet, the dfeat fc« conf.ffored the IPvf. C^wn^f 

^dr»» md wheTihe cBeat has rtgisvered with the Honie Agent ov«r IPv6. 



Figure S.l: The oonfigtirfttion dialog in the Roannne Qienb. 


5.5.5 Testing and Debugging 

The cBent iaiplomontotion could ea^ly be tested agwnst the Home Ag^"^^ 
m^^aTn. D^S testing h was fou«a th^t the decapsulatloiL of t^n^d 
ta^^SeAsBrt did not work coire.«Jy. however this ejected with a nnaJl 

''" Ttebugging of the MobUe IP drSvet was g«»tly wmplilie.! ^ the use 
p«S»ScB debugger. Without a proper dcbogger fbr tho driver it w„uM liave 


otST AVAllLABLE COPY 


15/01 ^04 18:37 FAX 46 8 31_iL67 


GROTTH & CO 


^ BANNER & WITCOFF Si 043 


been very time consuming to implement the new ^mcttonality in the drlvcp, Tlje 
debugger in MicroSbft Vfeual Studio .NET was used dxirinff dcv^opraent oT the Mc^- 
bile BP service applic<ution. Bthsroal was iised axcenaivgjy dunns de^^toi«»«?J ^ 
wetXfy tbat packets seat to and IroHi the Mobile Node were wiistni<±od correctly. 

5.6.6 Conclusion 

The implementation of tho nc^ Mobile Node Rm^ion^m ^ f out 10 ^ 
complete. T-hio impletaewtetlon iwa seen to be the naky part of the project* but 
^th good support LiA people at IpXJnplueged. the new MobHe Node ftmctaouaMy 
wea successfully impJeniexited in tlio noamlsg CHfidxt. 
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Chapter 6 

Evaluation 


6.1 Introduction 

The evsauation of the ntiplementatSon was done Iqr verJ&iwg i-liat the gpals of the 
project waa met. As the wsulting jmplementaHon was set to b« a proUj^e. only 
the necesaxy parts of the so\vti<m needed for a wrifine prololype «we tested and 
evaluated. F«xturca of tJbe aolution that may have beea affected 1^ tte ?o^^^"S« 
should -be verifi6.1 thr wishly whea the protolgTpe funCtowiahUy » to be anplomotttcci 
la vhe final product. 


o 
o 


6,2 Network Setup 

The implementabion was tested end evaluate ixi -a local t«st eaviromnwit. The 
test network was set up to allow leatmg of tbe clSeikt from four tUffeMit <3rpes « 
iiGfcworlcAh tlie boDie nctwoyjt, co-located on IPv4, <io-tocaled on IPyS and co-locatcd 
ot) ft dual stack network. The resultin^r nctwoiic Setup is shown m ^ff™^^-^" 
additional R>relgn Agcirt, accefisiblo irta wSreles© netswrk was also used to ycniy 
fuTictiozKiIity from a foreJ^ IPv4 neftwork. 



■3 



Figure C.U Th» U»t nettwork fietup. 
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6.3 Verification of Goals 

Before the prototype w« imptemeintrrd * of goals ^-as set iip. T)i«f « goato 
8Bt as tha iDiTjiimun requiremfiirts for the prototype, any fcatun« mrtetOe ol Uiese 
goalB wi« not GO be focused an. Addit.ional goals ^ set up for Mujpjle Nocte m 
ordex to use Mobile IPv4 ove? IPv6 without the IPv6 stack instalfed m Microsoft 
Wlntiowa 2000/XP. 

6.3*1 Home Agent 

The followlmj Uei presents the goals ^et up for the prototyp^^ itopleuienUtion of the 
Horoe Agent and the resulting fimcLionaltty achieved by the unplementatkm. 

1. Xbe Home Agent has to be extended to hwdle Registration lUt- 

qnests over EPvG. 

ScBult: Tlie Home Ag$tA sticcewfidly handle* KeEaOratioo Requests ovier 

IPv6. 

2. The Home Agent hae to be ablo to send Registration Replies to the 
Mobile rifode over IPvG. , ^ , _ . . 
Reautt: Th« Hcm^-As^t seads Reglstr^woH Relies to ths Mobile Ncwle over 
IPv6, injfoniang the Mobile Node? of the' result of the tegtetrtttlon- 

' 3. The Home ^ient b^ to bamdjc the.iievir' li>v6 Cai«-of Address Ebc- 
teziBlon in Reglstratioii Requests. . ' ' - ' ' j M«.^+?fi«: 
Result: The Home Agent parses the Regprtratioa Requerfs ™S jj^^™ 
IPv6 Cwre-of Address Brtenstou and use, tihis addrpss as the Ckr^-of addreaa 
for tHe Mobile ::^odB. 

4. The Home Agent h^ to. be able to.decaP?«lateJ(Pv6 tunneled IPy4 
packets from the ^^obUe Node- * • , , ,« i , ^ 
Result: The-Home Age»t successfdlly decapsutete IPv6 tunneled IPv4 packets 
and sends them "to the correct deSsthai^towa ■ 

5. The Home Age»t has to bo able to encapsulate IPv4 paclceta hi the 

Result: Thft Hwne agant successftiBy enwpsulsrteB IPv4 padrnta Jn the IPv6 
tunnol. 

6.3.2 Mobile Node 

The foUowing list piweuts Uie goals sot up tor the prototrpe toplcmentotiofl of Uic 
MolnU Nocte and the iwnlttog ftmctl£*nftBty achieved by the Smplemcnt^tJoa. 

1. The Mobile Noda liw to bo nibte to seo^ «*«'«'Jf''^'*;''^*^* 
^4 profile Snfor««tfoii. la order to configore ^jLllS^/ 
use. The JPvS aadross baa to toe eonfisured usme tbc stateless ad- 
dress auto-conflBMra1*iiii method- 

Result- The MoMte Node succasrfMBy xecetves router aavertisementa and 
parses out the prefix totonnatiwi. Thta prefix InltorBtWion i» then '•^dto 
Sgtt*« «« TPva sddiess accordlxis to the method used l« et«Hl«w flrtdiese 
BUtoSlnfiguTetion. lHam^, -when no IPvS protocol is installed, sometimes 
dSee «ot receive »o»tcr edvertbemerts end neighbor 
The loason tor ihls is that WJudowe regirters » new i«ult,c«.t MAO 
list the* doee not eontain the neceeeery MAC oddrca« f«;^^P^ 
ofrolaw adverUsenHWte and nelflbbor diseoveiy wjeMagee. The -worlaround 
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for this pwblem is to pull the netwark cable and put St b«ck in. tWa triffffaiB 
the driver lo register the multicast MAC address Hat again. 

2- The Mobile Node has to ba able to sGn<3 Kesistration Bequests over 

]]Pv6, ueJ»iB the configured IPv6 sidclress as source address, and the 

Homa Agent IPv6 address as destination addr^ft*- 

Result: The Mobile Node sends Registration R^ueiJlB ovcsr IPv6 mice the 

IPv6 c«xe-of address has been configured. The Home Agent IPvC adilr*«» as 

ictfjeved from the cQnfijpmtion of the cHeozt. 
8. The Mobile Node has to be able to Inidude the IPv6 Coro-of Address • 

Xhctension in the ]riesi5tration llequest. 

Kesult: The Mobile Node attach^e the IPv6 Care-of Address Bxten^jon to the 
Itegistration Request when Co-]oceled on IPv6- 

4. The Mobile Node baa to be able to encapsulate IPv4 packets In ^ 
IPv6 headers, destined for the Home Aeent. « , * , • 
Result: The MolnU Node successfully eucapBolates outjgolAi; IPv4 pocfccta fn 

, II*v6 headers. 

5. The Mobile Node has to bo able to decapanlate IPve tunneled IPv4 

packets firom the Home AgenL. , . m ^ i 

Result: The Mobile Node aucceaafiUly decapfsulat^ IPv6 tunn^cfd TPv4 pack- 
ets aAd sends theni' up to the virtual adapter. ' 

6. The Mobile Node lw» to be able spUt tunnel IPv© trofiic. i.e. IPv© 
traffic should be sent directly out on .the mterfaco and not tunneled 
to the Home A^sat, This aHows the use of XPvS aervieea at the 
same time as IPv4- noobilit^r is used from an IPv6 aceee& network. 
Result: IPv6 split tunnelins is w>ii«ing coircctiy. It is however not possible 
to turn this feature oil. 

The fidOilional goals set up lor the Mobile Node was also implemented. The luldi- 

tlonftJ gocOs and the resulting fanctionplifcy are preswited below: 

1. The Mobile Node ahonld be able to notify the uetwork iwtwfhco | 
drivi*r to reccsive the t&ecessary multicfkst traffie in order to receive 
router adverfcisementis and neiglibor solicttatlom. This is somcthmt? 
that the IPv6 drtv^X normally a«e», but as IPv6 will not be installed, 
the Mobae Node has to do it. , ^ n 

RffiUlt: The Motile IP driver «^stete a multicast MAC address list with the 

network interftiec driver for reception of traffic sent to Ihe speciid mnltlcest J 
MAC addresfies used in rout«r advertisements end neighbor solicitations. TWs 
is cuirently only done wheneftfer the driver recognizes linV-up, Le. when the 
network cable Is coyinected. 

The Mobile Node should be able to respond to n^ghbor solicits- 
tlons. In order for the Mobile Node to behave as an IPvC node 
among other nodes in the net^rk, the Mobile Node shouhl fully 
support Neighbor I>iscovery, but for a minimca prototype hnple- 
mentatlon it Ss enoufih to reapond to neighbor solicitation. Neigh- 
bor sollcitatioiw are gent as a query to get the MAC ^^cldws of tiie 
node, if the Mobile Node does yiot respond to these EoMdtatlons, 
IPv6 packets Crom the IPv6 router in the netvirork camiot bo sent 
to the Mobile Nodei. 

Result: The Mobile No^e can receive ncighl>or solicitatnai» and send out 
neighbor Advertisements to «oli^tatlng nodes. 
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6.4 Porformance 

Hie perfoTxnance of tho Mobile n*v4 ovex IPv6 solution wUen co-locnted oxi IPv6 
hod b^eao moasuied and compared to co-located on TPv4. The pet^formance of the 
prototiype iDiplcmentation id not >n any case Tcpresentable cf tivs performance of 
ipUnplugged's Mo^le IP solution, due to the esctensive c:han^ in (he ^:or)o and the 
quality- of the tejrt nortwork. lb start with, -we can theoretically calcnlaCe how big 
the relative perfqrtwftnce decrea3e ahtnilrl be •when co-locol^tl oki IPv6. 

If aB&tiine that the IPv6 roiitij)g is as fast aa IPv.l routing, we know that the 
IPv6 header as 40 byt^s compared to the IPv4 lieadcr of 20 bytes. Thia gives an 
additional overhead of 20 bytes p« packeU for tb« Mobile IPv4 over TPv6 soiliitioa. 
If each packet id 1500 bytcs^ this gives st pexfoiina^ce loss of iranaAfrrod d&ta at 
ahout 1.33%. However^ one must also baloe into accomtt the perfoni»Htico cost of 
the addition of on IPv6 stAclc in the Roaming G^Ltewiiy, and the new data 
stractures used to hold IPv4 and IPv6 addbresses xn thti Mobile IP unplenientation 
on the Roaming Ga.leway, aa wdl as the new data stxvf.'toycs used In the Ko^jirg 
Ghent. This cost Is dilEcult to calculate, therefore Bome basic porfonxiance l«»tJijg 
has been done. 

6.4.x Kvaluation Method 

Th© perfonnance of the;s?J«>to47pft was cval^ted usiijfs the TPTEST [TPTBST] 
.server version S.IO and client version 3.0.JflJ..iTi:\e^T^Tl»j{3'4.* Rftrvcr is runnine: on the 
IPv6 router in the test netwark, and thi3i/TPJ^l^T, bii^t/iatrnnning 0» Windows on 
the IVfoblle Wodc. rChe tests were 

two laptopd nnd a Booming "Gateway, vrhere rae laptop '^nsb5 used as Mobile Node 
and one A3 FPv4/IPv6 Tout^. The lOUVer i* conuectfed to thQ Roaming Oa-tcway 
through A 10 Mbit/s*ftiib. Teals -wwe done-wldli; c^bteied«C<>-IciCf«trid behind the 
lOut^jr On IPv4 and IPv6,*T¥ith JPsoc tunned ofT. One test con^ished of i.mttfimif^f^nn 
ftj^d tecftptton of ftvo msgabybe .of data to 'and tn>m tli« TPTEST serv^ ii«#ng the 
TCP protocol with staaidard ssitmg^ in 'i^l'JBST. The tost -was repe^^^t) lO times 
fbr ecuiO) type of access method, totsdlxng t9 20 lest rtins during the evaluation phase. 

6.4.2 Results 

Tho tcaults of the test runB showed Co-located on IPv6 using A'fobllo rPv4 
over IPv6 has znloimal per&noanve loss over Co-locatod on IPv4. Th«t tnftasurod 
perfbrmanco loss when Oo-located on JPv6 compared to Co-located on IPv4 was 
only 0.25% -whou sendho^ data, and 1.32% whea receiving data. The meafiured 
msnlts ore very close to thetheoxelical calculaftion, ^d should be barely noroiiieable 
for the usor. 

If thne allowed, amore extenelve evaluatioxi of the perfonnsuice <io\*)d hav« been 
done, with loss bottlenecks in the network such bh hobs and old 10 Mbit/s network 
lAterfftceft. However, due to tlma oonstrajzits such m evaluation could not be dome. 


6-5 Usability 

As the ixnplenxoiztatlon of the Mobile IPv4 o\vr IPv6 solution -was 9iiu<-:d towards 
a prototype, the focus h»« not bcHc t.w mafett the Roaming Client and Gateway as 
user fidendly as potable- However, the usabilliy of the solution is quite j^ood fbr a 
prototype. 
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6.S. CONOLVSTOm 
6.5,1 Roaming Client 

Tf the dient. is configured correctly, ix. configured with the IPv6 ««i*[ess «r the 

^^poiiits. «3er d^es not need lo be «««e "^^'^rpe .rf »^ .«^Ork 
taansttlon Is txaDfipaxent to the «sar. It !s pos^ble to get detato about tte 
^^^y C^««.f address. Home Ag=nt etc, 5n the 
control appJicfttion. If »o IPvG tLppJications are used, then nt la noic *f 
tteSrKctVn W "Zvs, as th. cli«.t can operate oa JPv« ^*»'°f*^ 
wTnd«««IPSr6 stack. Ilov^ever, if the user v«Bite to «ee IPv6 i»t»araiiM, »»! thet 
Sl^^bl do««*^> Aall the JPV6 ««ck by typms ^ S«stan- co«>«.a«d 

in A console. Thfo only >«orlss Windows XP ydth SFl or iwv«. 

6.5.2 Roaming Gateway 

The Hoaintog Gateway needs manual c.w»6Bur»d50D ui Older to -work correctly. Due 

^Vmft^ly IP addresses can be eMisned to faterfeces using a. CU commimd or the 
S^iSdB^.nun« Server. atomanueDy 

root i on the itoaminB Gateway is needed. In tho eh^l the ifcoofig and 

«e u»ed to Bet JPvS addresses ^ tcbfigm* default routes. 

6.6 Conclusions • ' 

The overall conclusion of the ovaJuation of the prototype i^lhal il worke ^ exP^cteA 
The prototype Is qeite easy to iostaU and use. but It could need 
inthoccarfl^ration of tho Hoatning Gateway. The f erform«.T,c« of the pmtotype ia 
xelsttvely e»od eumridmng no perfoimttnco «H>hiHt«w««nte! h«w> hnnn iw>iii~ 
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Chapter 7 

CI 

Conclusion 

to thte Chapter I t-^UI Bummajize the work done during the master thero» and PM«m* 
SeiLt important r«2sult3. I will also preseirt intcrcstliie work e:^^«=«5 gathered 
during tha 20 -wotJcs. lastly, oventuaj tnrthw wak will be «ittS«*ed. 

7.1 Stimmsiry 

lhavedurlarftlileina6tOTthedaieniaiob<*ftUot»Xtoplvgee«J,]Pr^^ 
^dSt»nfopTvIobilelPv4tlwd;iUk«.mobiteu««ton,»i^^^^ mobJ^ 

IPv6. The implemeatatwii oT tUe p<rcrtci«gT>e was based on ipOnplaSged s soI*^o= . • 

support the MobOe IPv4 ovBTlPi^sautto^^ • • 

roobili'ty for the \iser. ' " , j_ , , j j* 

I have evrfuKted tie pwtoiype m laacticiJ testa in a. network lab Mid it shows 
good p2U«««i« in coip»«^wia» nor«al Mobile IPv4. The ^^'l^tV «f ^« , 
^taltetion end w»bo of the dteit is v«iy good, it is not necessary to ma*?" W > 
IPyC Btadc «o tiee Uie new wlulion and the nser does no* need to bo ^f]*^^ 
T»tern^rotoooliscim«tly iised iahf«d-BVBrabet^ ac««. networta. arft totally 
Mid fiw of suonutl oonaguFatlon for the user. 

7.2 Discussion 

The next gonerfttlo« t»iter««t pioBocol. JPve. is by many believed to be a toy com- 
ponent of the nex. g^eration of ceaulor networte. This la f~bablyd«o ^ the 
vast amount of handheld IP devices that are ojtpected to be i«ed <*«>»«n<«'*^°^ 
world once the neoct generation of cellnlar networlaa are seorted Co be dePi^red. The 
reason for the exported «no«Dt of devices is the '^J^^Pff^^J^^t^^ 
generation cellolw net«-orte that altov traasportaSion of data a* 4 mii«*i 

thin prtioM«ly ever posMbla. The handheld dcv1«« can T'^^^^^^'^^ 
service with a high speed data cormfftton, such « '"^^^^^ ^'J'^f 
high speed luteruet acaas etc. With these new posdWUtteB «t is likely WW ?^ 
uew network we going tobe ..8.«1 « ^^^^^f^^r^SS^ 

need 9. hieh speed Internet connectfoii white on the move. Some of 
^« arefoine to need the posglhllliar to securely access ttotdt ho>fie M6rw»rk to .»3e 

adiicve IPv4 mobility does not woik when tho user Is connected to an TPv6 access 
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network As previously dJseiisstsd Jn tjife th«is, ther* hi* solutions wliows MobUe 
IPvB can 1>e used to achieve IPv4 mobUity lroialPv6 access networks, ;^ua logetlier 
^th Mobile IPv4 thfe will (OlQW eewnlces aaobaity between acce^ n^works ufliii| 
diffij^t vwjioiw or thelnlemet protocol. But it Ib not likely Ih^ IPv6 win be W 
in the bome networka imUl the Tang^ of commfirciia applications supporbns IPVG 
ifi big eaougli and usere feel the need to use IPv6. For this reason, I beHevo tl^ 
Uers «re not going to invest mon^ in Mobile IPv6 solutions until 3Pv6 is actually 
wsed ia the home network. . j 

The MobUe IPv4 over IPv6 solution proposed in this master thcsjs, can be used 
lo get IPv4 mobiUty fiom IPv6 access netwovks viitbout the need for inv)nstm«its m 
Mobile IPv6 mfcistmctUTe. Tlie soluUoii is rdativeiy easy U> impleinen J For Mobile 
IP vendor, ci«rtii»«i^ to the vwk needed to implement a rull Mobile IPv6 solution 
TTith siipuoxt lor IPv4 in Mobile IPv6. This will keep the cost down for companies 
and vendons 4md will allow nse of IPv4 mobility from tho n«^ gcnerataon access 
networks uwng IPv6. However, as soon as IFv6 Is doployxxi in homo networks and 
appjications and services in Oiese netvrorks arc starting to '^^y^^:J^!^^fffj::l 
Mobile IPv6 .oUilionsere needed to support lPy6 mobility When IPvC and Mobile 
TPv6 is xteed in Ihe heme enviiomnenC and aM hosxs aie dual stacked, tli^ i« «<> 
10W4W any need for Mobile JPv4 ov«: IPv6. Instead it is preferable to j^c TF^I 
Mobil© IPv6 as this solutkyn can take advantage of tlie new U^tnr^ m Mobile iFv&, 
lb conchide. 1 believe Mobile IPv4 over TPvg is a fiood ssolntlon to duriug the 
«er5od when IPv6 access 'iw*TOrkai axo a^^lftblei^-but hofn*- networks Ar« $tiU ueins 
IPv4 as the main network protocol tor th& inJfemal services- I also believe that a 
sola lion like Ibis can help to speed up tbft deadcyment of IP v<^ In access nt-cworks and 
the acceptance of IPv6 in (^eneralj ai* it aUuWis jnKjihnc lidcn? 16 fuUy ialcc ^"Jvontago 
of the next gcnoi-atldn c«llul»r networks and ^adualbr getTaocseptance for IPv6 and 
to iinally replace IPv4 in-thfe Kbmfe notwdrii as wdl^ *-.'>" • * 

7.3 Work Experiences 

BcfbTe this masler thems I had nci woirics about tlie inn»I«'^e»»^*'"5n on Or.eijB9D 
in the Home Ag^nfc, instead I beUeved that the vteky part of Idio master th^I^was 
the Mobile Node implementation on Microsoft Windows, as 1 have never OeveJoped 
drivers hi Windows before. However, the implementation tt«r«ed out vreU cm botJi 
the Home Afient and Mobile Node. T got help from people at ipOnplugged whenevor 
I hAd questions regarding their impltiniejimion of the Mobile Node and Home Agent. 
Without their support I do not believe th«t the prototype would have ended up to 
be as sncocsslul us it did- . 

During dcveliWMW^ of the new functionality in the Home AffSfiit arid Mobile 
Node. I havo gathered knowledge in programming of large acolo ^PPl'j^^*?*=*"^: 
plications can easily become very complex: and It Is important to stay to the ch«sen 
oc^tecfcure and not cut any comen* that you t^U end up regretting m tf^*^/^^;;^ 
The importance of good tools for debu^g are not to bo nnderestlmated, espe- 
aSy when it com^ to kernel development, both *RSn development and driver 
development iu Microsoft Windows. 

7.4 Further Work 

There arc still «. lot of work do be done in order to get a r«li*H«e <iii«^.y vendon of the 
Mobae^v4 over TPv6 ..oJ..tipn. Tb start with, the Roaming Client has to support 
different mechanisms for eonfi^urei.ion oXthe IPv6 care-of «^<i^^^?,^V A^r« 
n^rke. Additional mechanisms that should be supported are Stateful Address 
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7-4. FUJITJUSRWOPK 

Aut«>conasuratioa and DHCPvS. If the client is swposed to X'lSl*'" pL'JIZ"^ 

^^A^^f wSiflPv6 S^7S^^tl« Mo«le Node «n »end U« 
h,int irt TPvH firewall that li«sto 1» lPv« Mttbbd ftiid easily «nfigtt»abl« with 

«i» n^o«id be ««ie .» "-j^'fr^r:^ 
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